Fun times with iOS development
A few years ago I got an opportunity to work on a Xamarin mobile app at a small software company. These are some notes and messages I found from that time. Kudos to developers who have to deal with this absurdity daily, I don't know how you do it.Just in time
Went to check on company's iOS app, Apple declined the new build because it crashes when using the camera on iOS 14.3. iOS 14.3 was released Dec 13th, I submitted the app for review on 14th. Bleeding fucking edge of technology.Sideways photos
Want a fun fact about iOS? Using Xam.Plugins.Media library, taking a photo on iOS 12 or 14 orients it correctly, but on iOS 13, it's sideways.Building an iOS app, the fun and easy way
First of all, it's impossible to build an iOS app on anything other than a Mac, so we have a Mac at the office specifically for that.Boss: We need a new feature in company’s iOS app.
Me: This feature already exists on the website. Can I adapt the website for mobile browsers?
Boss: No, we want it in the app.
Me: Sure, I can add a WebView to show that specific page in the app. We already use WebView for another feature.
Boss: No, app stores will not like this, they will probably not allow us to publish the app if it's mostly WebView.
Me: Ok...So I spent a month reinventing the wheel in Xamarin.
Then one day...
I updated Xamarin libraries. Now I can’t build an app for iOS anymore. IPA archive is not being built on the Mac, process stops at creation of EXE on my Windows machine. No errors.
Spent a day reading outdated tutorials, found the “new and correct” way to do a build.
Apple now requires an iOS device to be plugged into the Mac that is performing the build. For whatever reason, probably so people don't use emulated Macs (mac-in-cloud services etc). So, a money grab. Had to drive to the office 30 miles away to literally plug in a phone. Thankfully we had 2 test iPhones, so I still have one with me for testing.
Build failed. Some file not found.
Aha, path is too long, there are two dozen nested folders and the length exceeds 252 characters (and it’s not even node_modules). Put builds in C:Temp, this should work.
Build failed. No corresponding publishing profile found. Fiddled around with certificates and profiles. Build successful! Now this app needs to be archived to be published.
Archiving failed. Unable to sign executables: file not found. Read more documentation. This is a bug in VS, but it’s easy to work around it in XCode on the Mac.
App archives!
Published the app archive to the App Store. It’s not in App Store Connect 2 hours later. Suspected it failed silently. Published the app again. Nothing.
Asked my boss if he got any emails from Apple. Yep! The config file is missing 2 entries that I was not warned about during compilation or archiving. Added 2 missing entries.
App published to App Store Connect! Testers and daring users can now access the app through TestFlight.
Suddenly, I am moving onto “high priority” projects.
Building an iOS app, part 2
Three months later...Boss: Are your changes still in the beta app? Some user mentioned they can’t use the new features.
Me: TestFlight builds expire after 90 days. I was working on “high priority” projects and heard no feedback on the app, so beta never went to production.
Boss: Can you re-build the same version so it’s available again?
Me: OkTried to rebuild.
Certificate expired. WTF, I made one when I started working on the app and they last for years. Oh... When I started, I created the iOS (specifically iOS, not Apple) certificates, which did not install properly on a Mac. So in reality, I was still using a very old Apple certificates created by the previous developer. And I managed to copy them to my Windows machine, too. Requested and got a new Apple certificates.
Tried to add the new certificates to Visual Studio. Apple certificates window in VS idles for a long time and then throws an error. Did Apple change their API?
Updated Visual Studio. Updated Xamarin. VS tells me Xamarin on Mac is out of date. Updated Xamarin on Mac. VS tells me XCode on the Mac is out of date and might cause errors. To update XCode on the Mac, entire OS needs to be updated to Big Sur. Tried to download the OS update. Not enough disk space. Deleted some old builds. Downloaded the OS update. Tried to install the OS update. Not enough disk space. This Mac has a 120 GB hard drive and somehow it’s almost full (there is nothing there other than default apps, XCode, and VS for Mac). Found a gigantic 60 GB cache folder within hidden folders under my user directory. Finally, enough space. Updated to Big Sur. Updated XCode.
Tried to add new certificates to Visual Studio… the same error again. So it’s not VS, Xamarin or XCode. Can't even archive the build on my machine anymore, so looks like the only way to go is to copy code to the Mac and build there. Copied code, opened VS on the Mac, tried to build. .NET library conflict between 2.0 and 4.0. All answers point to it being an issue with Visual Studio on the Mac.
So I’m stuck. Start trying random shit. Cleaned caches. Removed old certificates. Removed the iOS certificates from the Mac... Bingo. Apple certificates window in Visual Studio suddenly works. So that was it, iOS certificates that existed on the Mac were somehow screwing up Visual Studio. All the updates I made that week were not necessary at all...
Sign in with Apple
App store submission failed: Your app does not implement Sign In With Apple. Why the hell would we need that? Oh, per Apple policy, since our app has Google Sign-In (for customers with Google suites), we are required to have Sign In With Apple too. Read some docs. Sign In With Apple button has to be a precise size, shape and font. And it has to be the first suggested option for sign-in, before Google or any other SSO logins. Yes, requirements are that petty.Well, onto implementing a feature that will never be used. There's some decent documentation, and our backend supports other SSOs. Yet the iOS simulator... does not support native Sign In With Apple. So this functionality for iOS 13+ can only be tested on a physical device. I should be able to build, deploy, and test the app on the test iPhone that I have with me, right? Well yes, but actually no. After fiddling with VPN on the iPhone, and its connection to the Mac, deploying to the iPhone is so excruciatingly slow, it is somehow faster to publish a new build to TestFlight and install the beta from there.