iOS Development Diary Part 1
How Did We Get Here?
I’ve been obsessed with writing computer programs since I was 12, and been gainfully employed doing so professionally for the last 20+ years using the likes of C, PHP, Perl, Java, JSPs and Ruby. I’ve really settled on my preferred toolkit and platforms, and what I enjoy the most is building products and services for the web, bringing them to life and to global audiences. I’ve gotten pretty good at it, and my go-to toolkit is Ruby on Rails, as it has been since soon after the framework’s introduction.
As I wrote about here previously in a post titled Talk About a Revolution, I feel Rails 7 is an inflection point where so many stars have aligned, making the Rails framework even more suited and relevant.
So, in toying with some product ideas around my health journey, and then seeing the power of Apple’s HealthKit ecosystem, I started to explore how I could access the incredibly rich HealthKit data stored on my phone, and leverage it in my Rails webapp.
After some exploration I found there is an option in the Health app on iPhone to “Export All Health Data”,
but the process is laborious, and worse, results in a huge export.xml file of 800MB+ being output. Even
worse still is the convoluted format of this document. I wrote a parser, and it works well, but I can’t imagine
any real users doing this export-extract-import process on a regular basis. I didn’t even want to myself!
I knew I needed to look into how to access HealthKit natively on the device from my service…
Turbo Native to the Rescue
As luck would have it, along with Rails 7, the Turbo Native framework is really coming of age and seems to offer the exact thing I needed - a native app that leverages everything in my Rails app but then with the ability to enhance it with any native functionality I want! Amazing!
As I wrote about recently I was able to spin up a Turbo Native iOS app that wrapped a Rails web app very quickly indeed. This was really exciting. I was hooked.
Reality Bites
Having got to this point, I wanted to dive in deeper. I needed to integrate the HealthKit data somehow, and then sync that to my Rails backend.
I’d whiled away some time on a recent flight to Japan reading up on the Swift language and syntax, and was pleasantly surprised at how “Ruby-like” it felt. Promising.
As quickly became apparent though, even with the mountain of excellent information in the Apple Developer Docs, and numerous fantastic resources and tutorials on YouTube, I realised I needed to take a step back and dig in to some of the fundamentals of the iOS platform, frameworks and best practices to really make any progress from the basic app wrapper.
First Impressions
The number one thing I love about Rails is the consistency, the convention over configuration, the whole Rails is Omakase mindset. That really resonated with me from early on as it still does today, that basic principle of following well thought out defaults and strategies is huge.
That warm and fuzzy feeling has only been amplified after looking at Swift and iOS development, that seems to lack this kind of thinking entirely. Even the basics of something seemingly trivial like how to organise files and folders left me uncomfortable. I asked some iOS developer friends, and also those working with Turbo Native and received some suggestions but all different!
In terms of architecture, I initially read a lot about the Apple “MVC” pattern. Great I thought! I love MVC. Rails is MVC… but yet … no. iOS MVC is a “different” kind of pattern, just different enough to be really confusing for me at least. I guess it makes sense. Rails is a completely different paradigm of request/responses but that’s how my mind works when I see the MVC moniker.
Down the Rabbit Hole
The more I read, the more I saw “MVVM” being mentioned as the answer to Apple “MVC” which seemed to have attracted the secondary meaning - in addition to the intended “Model View Controller” - of “Massive View Controller”! OK! So MVVM. “Model” “View” “View” “Model” right? Hmm. Not exactly, but subtly this acronym actually means “Model” “View” “ViewModel”.
Unperturbed I ploughed on and read and watched many tutorials that started to make some sense. My main enemy I think is still the plethora of different “best” ways to architect an iOS app. I’ve followed numerous ideas like MVC and MVVM as mentioned, then stumbled on the “Coordinator” pattern which seemed a bit more like Rails controllers at a high level, which lead me to MVVM-C - Model View ViewModel Controller. All the time I was rebuilding an app with my Rails app as the central point, and this was quite a good way I think the get a feel for what resonated with me or not most.
Next Steps
As I write this, I’ve come a long way, I’ve been able to integrate native screens into my Turbo Native app, added a tabbed interface and hooked in to HealthKit - at least to the point of bringing the permissions sheet up when trying to access it. It’s really sparked that excitement in me when learning something new.
I’m hitting more challenges now though and that’s simply from jumping in too deep too quickly, so now my plan is to step back a bit, and go back to some of the fundamentals, learn more about the iOS app lifecycle, improve my understanding of navigation and SwiftUI and the basics of how iOS apps handle state etc.
I’ll write up the next phase of this journey in a few weeks and lets see how far I get! Hopefully I’ll have the same level of interest and progress to report on!