Written by We are incredibly pleased to announce the release of early-access version 1.0.7 of Flint. This is a big release for us and it’s all about the purchases and Cocoapods! We’re getting much closer to a final 1.0 release with this one in the bag.
This represents the final high level features required for us to ship 1.0, and it is tweaks, bug fixes and unit tests from hereafter.
Let’s have a quick run through what’s in the release.
Features that require purchases can now be verified using Flint
Until now we had support for the purchase precondition on ConditionalFeature(s) but there was no implementation of PurchaseTracker that shipped with Flint. This protocol is how we abstract checking the status of product purchases.
This release adds StoreKitPurchaseTracker which is used by default if you use Flint.quickSetup. The implementation is deliberately very simple — it will observe the StoreKit payment queue and store the current status of one-time purchases in a text file on the device. There is no cryptographic receipt validation, but you can implement that if you truly require it.
We’ve also improved the Product API to support non-consumable, consumable and subscription types. Flint will pass these through to your PurchaseTracker implementation so that you can check if the user has made the relevant purchases.
Setting up features that require purchases couldn’t be easier — declare a purchase requirement on your feature, and you’re done!
See the new purchase guide for full details and samples.
Debugging features that require purchases is easy
We added a new DebugPurchaseTracker that you can set as your purchaseTracker, to either act as a standalone fake in-memory purchase tracker that you can call at runtime to set purchase statuses, or to proxy your real tracker so you can override the real status during testing.
This makes it much easier to test your code for all the various purchase statuses and combinations.
See the new purchases guide for full details.
New debug UI for browsing status of purchases on iOS and tvOS
Whether or not you use the debug tracker implementation, on UIKit platforms you can use FlintUI to access the new PurchaseBrowserFeature which will present a list of all the purchases required by your features and their current purchase status.
This makes it wonderfully easy to see what your app believes the state of purchases to be, which is critical for the often confusing task of testing various in-app purchase combinations.
As a bonus, if you do use the DebugPurchaseTracker this same UI will allow you to override the current purchase status or remove your override so that the real tracker (if you have one set up) is used.
Cocoapods support is here!
Thanks to initial work by @hishnash we pushed forward and made it possible to install Flint in your projects using Cocoapods. We jiggled some things around and finally got it working.
We still prefer Carthage as the dependency manager best fitting Flint’s approach, but if you need to use Cocoapods you simply add one or both of these to your Podfile as necessary:
pod `FlintCore`, `1.0.7`
pod `FlintUI`, `1.0.7`
Please let us know if you have any issues or suggestions on the Cocoapods integration.
New terminating Action types
Using Flint you will have found that you often create “empty” Action types that serve only to handle analytics and/or logging for “done” or “dismiss” actions.
To make this less work, we’ve added two convenience types. Your Action types should conform to these, and that is all — no need for any other typealias declarations or perform implementations thanks to Swift’s protocol extensions and default associated types.
Here’s an example:
final class ShowProfileFeature: Feature {
let dismiss = action(DismissShowProfileAction.self)
...
}
final class DismissShowProfileAction: DismissUIAction {
static let analyticsID: String = “profile-dismiss”
}
ShowProfileFeature.dismiss.perform(input: .animated(true))
Fixes and improvements
There’s a small breaking change that is not likely to affect you, but assignments to Flint.purchaseTracker and related dependencies is no longer permitted. To customise these, use the new configuration closure argument on Flint.quickSetup and Flint.setup.
Flint.setup(MyFeatures.self) { dependencies in
let storeKitTracker = try! StoreKitPurchaseTracker(appGroupIdentifier: FlintAppInfo.appGroupIdentifier)
dependencies.purchaseTracker = DebugPurchaseTracker(targetPurchaseTracker: storeKitTracker)
}
In there you can set your dependencies on the provided object. This change means we can ensure you have logging setup before your custom dependencies are created. Also the default purchase tracker and user toggle implementations are only provided now if you call Flint.quickSetup. Otherwise we assume you have set your own in the closure or don’t want them.
The display of some debug information in the FlintUI view controllers has been improved, including how URL routes are show, how purchases are described, and the status of purchase preconditions.
We also moved some code around using a new pattern of folders for code that depends on specific frameworks that are we not available on every platform. For example we now have some UIKit-Specific and Intents-Specific subfolders. This makes it easy for us to exclude inappropriate files per platform in the Cocoapods podspecs. It is unfortunate that Cocoapods makes us do this instead of honouring the target inclusion of each source file which is how Carthage works because it doesn’t try to rebuild your projects… but this solution seems quite elegant and useful even if one is not using Cocoapods.
1.0 is coming
Yep, that’s all the major functionality required for a final 1.0 done. We’re on mop-up and improving test coverage now. Exciting time!
If you have any questions about Flint please get in touch via @flintframework on Twitter or our Slack.
All the API and guide documentation has been updated at flint.tools, as has the Flint Demo project which now supports adding voice shortcuts to open specific notes.
