I’m not a fan of “web versus native” debates. I think web apps and native apps can be complimentary: I use both every day. And while the web is my current area of focus, it wasn’t always that way, and occasionally I still find time for a native side project.
But I’ll admit to feeling a bit spoiled by the web whenever I pop back into the native app world. That may seem surprising, given the web dev community’s reputation for fair-weather frameworks and increasingly complex build processes. Here’s a story explaining what I mean…
Back in 2016, I made an iMessage app called Overreactions. Actually, the term “app” is probably generous: It’s a collection of static and animated silly faces you can goof around with in iMessage. Its “development” involved many PNGs but zero lines of code.
Just before the 2019 holidays, I received an email from Apple notifying me that the app “does not follow one or more of the App Store Review Guidelines.” I signed in to Apple’s Resource Center, where it elaborated that the app had gone too long without an update. There were no greater specifics, no broken rules or deprecated dependencies, they just wanted some sort of update to prove that it was still being maintained or they’d pull the app from the store in December.
Here’s what it took to keep that project up and running…
I opened Xcode to view the project source, only to be greeted by an error dialog letting me know that my Xcode version was somehow too new for my version of macOS. I wasn’t sure how that mismatch could have happened, but I’d planned to update to Catalina anyway, so I went ahead and did that.
I opened up Xcode again. This time the dialog said that Xcode would not run until it had installed “required components.” I’m no rebel: I agreed to do so.
Once finished, I was finally able to view my Overreactions project! Hooray! Xcode detected three issues, but all were magically resolved by clicking the “Migrate” button.
I compiled the build to the iOS simulator, where it seemed to work as it always did. But before I could submit a build to the App Store, I needed to test on a real device.
I plugged in my iPhone, but the device wasn’t recognized by my developer account. Xcode informed me that I would need to accept the latest developer policy in Resource Center before I’d be able to approve this device.
I navigated to Resource Center, where I was able to view the new policy, but not approve it. It took some digging to figure out that I as an admin did not have the power to approve agreements: Only the account owner (my Backabit co-founder) could do so. I messaged him and he quickly helped me out.
With the policy accepted, I was able to approve my device for testing. I compiled the build again, and it worked just fine!
I began to “archive” a build for submission to the App Store, but was thwarted by a new error: A missing icon resource.
Although Xcode did not display any error or warning, the icon resource field in the project’s settings was displayed in red. It was pointed to the correct “iMessage Sticker Icon” resource, but it lacked any interface for selecting an alternative.
I researched the problem and found a recommendation to rename the resource to
AppIcon. This suggestion resolved all remaining error messages and would have un-blocked submission to the App Store, but the app’s icon no longer displayed correctly in iMessage, making it almost impossible to navigate to.
I tried a few other solutions, to no avail. Eventually I discovered a message suggesting that this issue was fixed in the latest Xcode beta. I decided to try the beta myself.
For no obvious reason (my internet seemed fine otherwise), the 8GB beta download kept failing within the first gigabyte or two. After many attempts, I eventually retrieved the complete file so I could install the beta. The commenter was correct: The icon resource was no longer red, the app compiled and run as expected on my device, and the build was archived without issue. Hooray!
I submitted that archive to the App Store, only to receive a new error: The build’s minimum iOS version was newer than the current stable iOS release.
I scoured the Xcode project for this minimum version setting, but all I found were references to iOS 10.x, which was several years old and clearly not the culprit. Eventually I realized that this was a side effect of building the app with a beta version of Xcode.
At this point, I was completely stuck. I could either submit an updated build that broke the iMessage icon, or allow the app to leave the App Store while I waited for the next stable version of Xcode.
I opted for the latter, and for a short time Overreactions vanished from the App Store.
The new year brought with it new Xcode updates. These thankfully included the icon resource fix from the earlier beta.
I couldn’t help but laugh when I tried archiving a new build and saw a familiar error: It had been so long since I started this process, a new policy agreement now needed approval. My business partner swiftly approved (again), and I was finally able to upload my new build.
Eventually I satisfied all of these requirements. The update was approved by Apple in a few hours. Overreactions returned to the app store, and existing users downloaded a 2.2MB update with no new features.
At several times during this process, I considered giving up. Ramps, my first game, took a lot more time to make, was a lot more successful, and we still couldn’t justify the time and expense needed to save it from the 32-bit app purge. Why even bother keeping this silly little self-indulgent sticker pack alive? Eventually it will become too obsolete to maintain anyway, and who will even notice or care?
The web is far from perfect, but I think we underrate how resilient it can be. I miss it every time I’m away.