Helge Heß:
Lighter is a set of technologies applying code generation to access
SQLite3 databases from
Swift, e.g. in iOS applications or on the server.
Like SwiftGen but for SQLite3.
[…]
Lighter builds upon the database schema and hence directly knows what it looks like at compile time. For common operations no mapping is necessary at all, the generated code runs as fast (usually faster) than hand written code. It directly binds Swift structures to the SQLite API.
[…]
Lighter itself is a small and convenient API to access SQLite databases. Enlighter, the code generator, can however produce code that just uses the SQLite API and doesn’t require any dependencies, i.e. tech debt.
Helge Heß:
With Lighter.swift it is often (significantly) faster to waste and always fetch full records than to do manual fragment fetches w/ runtime based SQLite libs.
Previously:
Code Generation Database iOS iOS 15 Mac macOS 12 Monterey Open Source Optimization Programming SQLite Swift Programming Language
Alexandre Colucci:
In order to get access to random files outside of the app container, you can ask the user to select a folder using an Open dialog. The app will then be allowed to access any file inside this selected folder… as long as the app is running. If the app is quit and relaunched (as you might expect from a command line tool), you will need to use Security-Scoped Bookmarks to keep this access persistent.
[…]
It all sounds simple… until you realize that a command line tool can’t prompt the user to select a folder using an Open dialog. The solution I came up with, is to prompt the user in the main app and pass the Security-Scoped Bookmark to the command line, easy right?
[…]
The main app can pass non-secure bookmark to a child process. How does it help in our case where the command line tool is not a child process? Well it turns out that the main app can pass the non-secure bookmark to the command line tool as long as both binaries are running at the same time.
This is a mess. It seems like command-line tools shouldn’t need to be sandboxed. If I’m invoking the tool from Terminal, it should have whatever access my current Terminal window does. Likewise, if the containing app invokes the tool, it would be limited to what that sandboxed app can do. I’ve seen conflicting reports on what the rules are, perhaps because App Review has been inconsistent in what it approves.
See also: Using non-sandboxed XPC service from Sandboxed app extension.
Previously:
Update (2024-03-05): Nick Lockwood:
Suppose I have a Mac App Store app with an associated command line tool.
I don’t want to embed the tool in the app itself, but instead make it available via a download link. What would be a good, App Store compliant way to make that available to the user?
App Review Dependencies Mac Mac App Mac App Store macOS 12 Monterey Programming Sandboxing
Celsys (via Jonathan Deutsch):
Customers with an Update Pass or a Monthly Plan (purchased through app stores or the Clip Studio Paint site) will be able to use the most up-to-date version of the app for as long as their plan or pass is valid. Version 2.0 will also be available as a one-time purchase (perpetual license).
[…]
The perpetual version will still get free stability updates when necessary to address major bugs in the app.
[…]
New features for the perpetual version will be included in each major version (2.0, 3.0, etc.), however, new feature updates will not be provided free of charge. Even if you have purchased the perpetual version of Version 2.0, you will still need to purchase an Update Pass in order to get access to new feature updates.
Previously:
App Subscriptions Business Clip Studio Paint Mac Mac App macOS 12 Monterey
