The App Store Small Business Program offers lowered commission cost with one big caveat: no app transfer. But apps graduating from a “hobby” into a “small business” would definitely involve transferring ownership. Read how to transfer apps without engaging in the app transfer process and losing out on the program’s benefits.
There are four types of in-app purchases in Apple’s App Store, with their own unique ways to manage it. The challenge is how to isolate the intricacies of these product types from the rest of the application. Otherwise a move from non-consumable in-app purchase to a subscription type would involve a major rewrite. Learn how to manage an app’s inventory of purchases and get the code base resilient to changes in the business side.
What if you need to create a “holiday special” in-app purchase? The item would only be available at a limited period some time in the future. However those who have bought the item would be able to use it beyond the purchase-able period, including restoring purchases should they need it.
I want to let some non-consumable iAP items just be sold during a particular period of time. Also the user who purchased these items still can restore and use it after the time period has elapsed.
Creating time-based in-app purchases (iAP) can be difficult. First all iAPs would need to go through App Review, hence they would need to be available before your app is live. Second is that there’s practically no way for the app to differentiate the app review environment versus the actual production environment – nor does Apple want you to.
But what if I say it can be done? What if you can have a non-consumable iAP, pass it through app review, and only made it for sale only during a specific period in the future? Interested? read on.
There are four types of in-app purchases in Apple’s App Store, with their own unique ways to manage it. Learn how to manage an app’s inventory of purchases, get the code base resilient to changes in the business side, and tips on how to implement some more esoteric business models as in-app purchases.
The data persistence stack that is an appropriate decision today may not be an optimal solution when your app has grown. You would need to design your app to withstand the test of time and be extensible for as it grows. Read more to learn how.
Programming Cocoa apps with Swift has it’s many caveats. Many of these are derived from the fact that there are two language runtimes at play, the incumbent Objective-C runtime which is used by system frameworks and the Swift runtime as a newcomer. Here is one hard lesson learned (and workaround) when dealing with state restoration problems in a Swift app.
Futures/promises are great to coordinate persistence and views to ensure responsiveness in today’s native apps. However bringing thousands of lines of foreign code just to have this small functionality may not be cool. Here’s a hundred-line implementation of futures/promises in Swift 3.1