“Do I need a Mac to program iOS?” – for a long time there is only one answer: “Yes”. But this is no longer true, as there are many ways to program iOS – including on itself. Yes, you can make apps on the device itself. Read this article to find out how.
When a table view asks for a cell, often images in the cell isn’t yet available and needs to be fetched from a server – thus the cell gets a placeholder image. But static placeholders doesn’t look as good as animated ones. Unfortunately cell views gets scrolled off and re-used which makes managing animations challenging.
Architecting applications to meet today’s challenges and be ready for tomorrow’s problem is not an easy feat. The principles of clean architecture may be sound, but separating the signal from the noise is tough. Here is a sample VIPER project for iOS that you can tinker to learn about the principles of clean architecture.
Compartmentalizing functionalities within an app to improve its maintainability is difficult. More so when you’re not well versed with software architectures and other software engineering principles. What if you can confidently structure your app to be resilient and adaptive to change?
Delivering a “minimum viable product” won’t be viable if your app isn’t going to pass App Store Review. Is your app “good enough” for the App Store? Is it appropriate for the App Store and not better off in the web? Read on to ensure your app pass the gates of App Review.
Providing “lite” version of apps had been the strategy to provide free trials since the dawn of the App Store. However these reduced-functionality apps fall short on demonstrating its full capabilities, which in itself be ineffective in enticing the user to buy. Fortunately that is no longer the only option available for App Store apps.
You try to reduce the application’s size by sharing resources in framework bundles and creating symbolic links so that other frameworks can find and use those resources. However this fell at odds with code signing (and probably notarization). Here is how to share code and resources in frameworks the right way.
When you’re just starting out in iOS development, there are so many options in which to place a button. There’s storyboard, auto layout, and even SwiftUI — that’s just scratching the surface. How should someone new to programming the platform chart a learning path?
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.
Do you distribute your macOS apps as .zip files? That has been quaint since Sierra. You should package your apps as signed and notarized disk images instead. Otherwise Catalina would say that your package is suspicious. However creating disk images is a rather involved process. Read on to find out more.
Distributing macOS apps within .zip files nowadays is no longer a good idea. One issue is app translocation. Another issue is the mandatory notarization starting from macOS 10.15 Catalina.
App translocation goes into effect when the user downloads a .zip file containing an application, extracts it, and runs it directly without moving it anywhere using the Finder. The operating system would run your app from a temporary read-only disk image created just for the purpose of launching your app. This has an unfortunate side effect of Sparkle being unable to update your app – which prevents you from delivering updates and bug fixes seamlessly to your user.
Notarization is the method to register your software packages to Apple when you distribute outside the App Store. The problem with packaging software inside a .zip file comes from the inability to attach the notarization result on to the archive. Therefore your user’s system would need to be online to check whether your software package has been notarized. Otherwise it would prompt a “macOS can not validate…” warning to the user, possibly causing suspicion to your package. However when the notarization result is stapled to your package, macOS can validate it without making a network connection to Apple.
Thus disk images is probably the best way to distribute application bundles outside the Mac App Store. Disk images can be signed, notarized, and stapled. When you distribute apps using disk images and Sparkle, your users would find it straightforwardly effortless to install, use, and update.
But creating disk images is an involved task for the developer. There are so many tasks involved to package an application into a disk image ready for the user. This includes:
Creating a blank read/write disk image for scratch-pad purposes.
Copying the application bundle inside the disk image.
Creating a symbolic link inside the disk image to the /Applications folder.
Setting a background image for the disk image’s Finder window to instruct the user to install the application bundle.
Use the Finder to carefully arrange the icons of the application bundle and the symbolic link to the /Applications folder to the background image, as well as any other additional content in the disk image.
Convert the scratch-pad disk image into a compressed read-only disk image.
Sign the disk image.
Upload the disk image for notarization.
Wait for notarization to complete.
Staple the notarization ticket on to the disk image.
That’s a lot of steps to do manually on each release. Thankfully all of those steps can be automated and added to your continuous integration environment. Hence you can automatically get a finished disk image on every release. Even if you don’t have a build server, integrating this to your Xcode build would be a snap. Read on to learn how to do this.
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.