Delving into Apple’s App Platform

Over the last month I dove into Apple’s Application Development Platform, which provides a unified set of APIs for developing software for MacOS, iOS, WatchOS, tvOS, etc.

As a Web Standards Engineer who spends most of his time thinking about and working on the Web Platform, it is rare that I would get such an opportunity to see how things work elsewhere… and let me tell you, it’s been quite a treat and really eye opening.

Note: in this post, I’m just glossing over what I learnt over the last month for my own benefit and to gather my thoughts. I intend to do a followup in which I’ll pivot back to how all this relates back to the Web Platform.

iOS Development bootcamp

My learning took place via Udemy’s “iOS 13 & Swift 5 – The Complete iOS App Development Bootcamp“, which is taught by a phenomenal application developer called Dr. Angela Yu. If you are interested in taking a similar journey, I highly recommend her course. But note that it takes about 3-4 weeks full time to complete, and only scratches the surface of what’s possible on Apple’s platform.

As the name suggests, this bootcamp was iOS centric. However, I got to build around iOS 20+ different iOS/MacOS applications (see the full PDF of course syllabus). As of MacOS 10.15, it’s possible to compile and design iOS apps a MacOS apps and they just work out of the box. So by just checking a checkbox, it was possible to run all the apps directly on my Mac.

Nevertheless, it was also cool to just hook up my iPad and iPhone and with one click have my apps running on the phone. And to be honest, it was often easier than getting things set up to run in a web browser.

Xcode

It’s a beast of an IDE.

The course covered most of the basics and getting around. Xcode has GitHub integration, as well as standard git support built-into its UI. However, it’s nowhere near as good a code editor as VSCode so I often found myself having to jump into VSCode to do things.

Working with Xcode’s WYSIWYG application layout tool was an interesting development approach. From my web experience, I thought it would have sucked because it reminded me of something old school like DreamWeaver. But it was actually quite ok.

The backing representation of xCode’s “storyboards” are a XMLs document… which is some twisted way, it’s like HTML although you never really interact with this document directly. These XML “storyboard” documents then link to code, via “IB” (interface builder) outlets and actions. These are similar to event handlers or just using global variables on a web page. For example, “@IBAction func addButtonPressed(){}” would handle a button press.

Xcode and an IBAction
Example of Xcode visual layout together with Code.

Swift

People who known me know that I’m a huge Swift fan. It’s without doubt my second favorite language after JavaScript – and gained even more respect for it throughout this course. Although the course didn’t cover every aspect of Swift (e.g., it didn’t go into the super powerful enums of Swift), it covered enough to be able to use all the APIs that were covered in the course.

Things I really like about Swift:

  • protocols and extensions in general
  • Data types
  • Easily insert variables “like by \(doing) this”… (yeah, I’m looking at you, Rust).
  • explicit argument names and aliased arg names. This makes for super nice, legible code.
  • immutable structs + passed by value
  • “let” and “var” only
  • enums and their shorthands.
  • switch/case behavior
  • Optional clousure declaration on final arguments
  • The do {} catch blocks, with explicit `try` declarations on functions calls. That way, one can explicitly see when a function will throw in code.
  • Automatic variable name generation for things, like “error” inside a catch block.

Things that Swift desperately needs or don’t particularly enjoy:

  • lack of async/await. The reliance on callbacks is very JavaScript around 7 years ago.
  • Building `if let x` pyramids of optional types.

It’s an amazing language that feels like scripting language and makes total sense to anyone who knows JS or TypeScript. But it’s a full fledged industrial strength no-messing-around proper programming language.

UI Library

The UI component library is rich and extensibly focused on application creation. Although there are similarities to what one finds in HTML with regards to common accessible form controls (buttons, text input fields, etc.), the platform provides a significantly richer set UI elements. It also provides means of extending all the provided components. This is similar to “Web Components” in a sense.

Xcode's UI library selection tool.
Xcode allows you to drag and drop UI components. You just search for what you need and drop it in place.

UIKit

Extremely good for creating application UIs, but the layout constraints system can be quite frustrating and I imagine takes a lot of practice to get used to. I guess it must feel the same using CSS Grid or FlexBox until you “get it”. However, I did appreciate the simplicity of just having to think about everything in terms of horizontal, vertical, and “Z” stacks when designing layouts and filling in space. That pretty much the same a CSS grid and FlexBox.

Example calculator showing horizontal and vertical stacks to do layout.

Documentation

Apple’s documentation is, as expected, fairly good. However, I think unlike a lot of documentation around the Web Platform, it does assume a lot of prior knowledge and can be at times challenging to decipher. At minimum, you are assured that there is some documentation for everything, even if at times it seems that it was automatically generated.

And let me tell you… having some documentation has been nice, specially coming from other open source projects where documentation is often non-existent.

MVC and Delegate model

The “Model View Controller” (MVC) design and the “delegate” pattern feature heavily throughout Apple’s platform. A delegate is essentially an object that can handle actions generated by other object – so you “delegate” actions, like, say, providing data to a data table, to another object using a standard “protocol”.

Although I personally find the delegate model somewhat fragile (as opposed to a subscriber model), it came to appreciate its consistency throughout Apple’s platform.

Networking and JSON processing

Personally, I think if a platform makes it difficult to fetch and process JSON over HTTP, it’s dead in the water. Thankfully, Apple makes it easy to spin up a “URLSession” to fetch data. I also really like that you can’t fetch insecure HTTP resources at all: you have to use HTTPS. Processing JSON is also fairly straight forward, but Encoding/Decoding (or making structures that represent JSON “codable”) can be quite tedious.

Thankfully, they’re are libraries like SwiftyJSON that make encoding/decoding arbitrary JSON data quite easy… though obviously not as nice as working with straight up JSON in JS in a browser or node.

SwiftUI

Swift UI was quite a treat. It again mixes layout and functionality, which can become a bit of a mess, but because of the simplicity of its layout model (HStack, VStack, ZStack), it makes it quite easy to lay out applications – and to control how items in each stack are distributed. Unlike with UI Kit, it was also nice to have direct control over everything without relying on Xcode’s WYSIWYG… but at the same time, you have to dig around to figure out where certain properties are hidden within various object structures.

Example application that loads up hacker news items and displays them in a UIWebView.

The @state and @published property modifiers where super nice, and something missing from the Web. It’s nice to just be able to set a custom variable/property and be assured that the UI will be updated automatically at the right time.

(Google’s) Firebase

Although not an Apple technology, it was interesting to play around with a third-party storage and communication service for building applications. In the course, we used Firebase to make a realtime chat application.

Storage

For storage, it was interesting to see the variety of different storage options available on the platform. These ranged from using plists, saving to files, using Core Data, using Realm, which is a third party database owned by MongoDB.

Core Data felt very ol’ school, while Realm was quite nice to use. I also found the defaulting to synchronous read/write operations with the Apple solutions somewhat concerning. Real seem to handle async operation much better.

Swift package manger

Unlike NPM, I kinda liked the Swift package manager’s direct integration into Xcode. In Xcode, you can simply point to a GitHub repository, and Xcode then figures that it’s a library extension.

Unlike using Cocoapods, SPM then sets everything up for you in Xcode without needing a separate project.

In-App purchases

It nice to see how in-app purchases are set up both within an application and also via Apple’s developer portal. It was also interesting to see how in-app purchases are classified:

  • Consumable – buy it, use it once (e.g., some kind of power-up).
  • Non-consumable: buy, and keep it (e.g., a sword)
  • Auto-renewable subscription, like a magazine subscription.
  • Non-renewable subscription: like access to a back catalogue for a year.

CoreML and CreateML

This was my first exposure to machine learning, so I found it quite fascinating and I was pleasantly surprised at both how easy the API was to use, and how easy it was to train a model. For images, you literally just create folders, drop in some files, and click a button in the CreateML application:

Data used to train how to recognize different animals: dog, cat, rabbit – along with data used to verify if the training worked.

At the same time, it was quite laughable how limited this technology is if not trained correctly (or without really understanding what it’s actually doing under the hood). And I have a fear that badly trained models will lead to really bad things happening in the world. Admittedly, I had a great time running around the house with my iPad (wrongly) identifying different plants… or identifying my cat as a “cat”.

Concluding thoughts

To say that Apple’s platform is anything but super impressive would be an understatement. Every API is filled with potential to unleash a mass of creativity, and Swift is just the right language through which to express that creativity.

Having said that, buying into Apple’s platform comes at a cost (a quite literal one!). However, I’d like to cover the tradeoffs, and how all this relates back to the web, in a followup post.

For now, it was nice to be a blank slate and just have the opportunity to explore a new terrain.

Privacy issues in Mobile Safari on iPhone OS 3.2

With iOS 4.0 around the corner, its probably timely to get this post out now. This little post is part of my position paper, “Privacy of Geolocation Implementations”. I’m taking sections out that paper and republishing them here for comment.

Iphone 3.0's modal geolocaiton popup
A website viewed in Safari on iPhone 3.0 requesting to use the end-user's current location. But what will the data be used for? And where is the application getting the data from?

As can be seen in the screenshot on the right, when a web page attempts to access geolocation services on Mobile Safari, the browser presents the end-user with a dialog that states “[URL] Would Like To Use Your Currrent Location” with two options: “Don’t Allow” and “OK”.

This “click to confirm” model suffers from a number of  privacy issues: For one, the confirmation dialog does not give any indication to the end-user how their location is being derived: Is the location-provider the GPS? or is it the WIFI, or the cellular network, or a Web service? or a combination of those? and under what privacy policy does the location-provider provide that information? The iPhone provides no accessible means of viewing or changing the geolocation provider; hence an end-user has no control over the geolocation provider or even of knowing if their data is being encrypted on request.

Another privacy issue of Mobile Safari is that the confirmation prompts are modal: the user cannot fully view or interact with the underlying application to make an assessment of what the application might do with the positioning data, without first rejecting geolocation access to the website. Also, it is generally accepted that this kind of modal confirmation dialog lead to ‘click fatigue’: whereby users simply become accustomed to clicking “OK” to every prompt without grasping the consequences of their actions, and without having any real control over what personally identifiable data gets used, what it will be used for, or how long that data will be kept, or even if it will be made available (sold) to third parties. The privacy policies that govern geolocation services are buried three-levels deep in the “Settings” menu of the iPhone, under the “Legal” option, which contains about 50 a lot of pages of legalese and no searchable index!

Iphone 3.0 Legal page
The Iphone 3.0 "Legal" screen does not contain an index. Nor are hypelinks active.

Similar confirmation dialogs are found in the iPhone’s native applications (e.g., the Camera and Maps applications). If a user changes their mind about allowing location services, there is usually no way in the application  for them to revoke geolocation access without either quitting the application, uninstalling the application, or finding some other convoluted way to revoke access to geolocation services (e.g., having to globally disable location services on the device through the “Settings” menu). What is worst is that  once a user grants an application access to geolocation services three times, the system grants access to location services forever – or until the device is “reset”, meaning resetting back to factory default settings.

UPDATE: @andreasbovens pointed out to me on Twitter that the iPhone does, in fact, contain a way to reset location warnings. Go to “Settings > Reset > Reset Location Warnings”. My bad.

Iphone reset location warnings
Iphone reset location warnings, which I didn't find the first time around 🙁

Applications that get granted access then do not generally provide an end-user with a means to revoke that access on an individual basis. This is also true on Mobile Safari: even after clearing the cache, history, and cookies Mobile Safari still grants websites access to geolocation without prompting the user.

In summary, Apple’s Mobile Safari browser (and iPhone 3.0 in general) provides end-users with limited access to privacy controls. It also provides no means of seeing which Websites have access to geolocation, nor once granted can that access be easily revoked by an end-user. The OS, however, provides means of achieving confidentiality by allowing the end-user to globally disable location services, WIFI, and cell-tower communication (via “Airplane Mode”). INSERT: The iPhone OS also provides a “Reset Location Warnings” option for all applications.

Iphone Airplane mode
iPhone Airplane mode: anonymity?