![\"\"](\"/media/server-driven-ui.003-1024x576.jpeg\")
Last week, I gave an impromptu talk at the CocoaHeadsNL November meetup.
\n\n\n\nI’ve recently been working on R.swift version 7, which adds Swift Package Manager Plugin support.
\n\n\n\nAfter a brief overview of R.swift itself, I demo’ed the way SPM plugins can be added to an Xcode project, as well as an SPM project. I then showed the two types of Plugins; BuildTool plugins and Command plugins.
\n\n\n\nIn the Q&A afterwards, people asked some great questions about SPM plugins and R.swift.
\n\n\n\n\n\n\n\nSee the R.swift project on Github for a full example of how to use SPM Plugins.
\n", "date_published": "2022-12-02T17:00:00+02:00", "date_modified": "2022-12-31T15:19:09+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2020/07/server-driven-ui", "url": "https://tom.lokhorst.eu/2020/07/server-driven-ui", "title": "Server Driven UI", "content_html": "Update 2023-03-29: In August 2021 Apple acquired Primephonic the company. On March 28, 2023 Apple launched Apple Music Classical as a new app. This new app is built on the foundations of the Primephonic app, the fundamentals of the Server Driven UI architecture as described in this post remain the same.
\nNote: This post is based on a talk I gave at CocoaHeadsNL in July 2020. Warning: because this is based on a transcription of a talk, sentences and wording may be weird or incoherent. The original talk, including a live Q&A afterwards, can be seen here:
\n\n\n\n\n\n\nOver the years, I\u2019ve build many different types of apps. However in one aspect they\u2019ve all been very similar; In the client/server architecture, the server sends domain objects to the client (encoded in JSON), and the client renders these domain objects to some pretty UI.
\n\n\n\nServer Driven UI is different. The server does not send domain objects, with the client having to decide how to render those. Instead, the server decides what and how to render, and just sends instructions to the client. You know, kinda like HTML\u2026
\n\n\n\n(Honestly, it\u2019s not HTML… But it sort of is. But really, it isn’t)
\n\n\n\n\n\n\n\nThis post is about my experiences with building and using a Server Driven UI in the Primephonic app.
\n\n\n\nPrimephonic is a classical music streaming service. It has apps for Android, iPhone, iPad, a web player and Sonos integration. Similar to Apple Music, or Spotify, but additionally there are lot of features that are specific to classical music.
\n\n\n\nWe build Primephonic over the course of a couple of years and we build it all using Server Driven UI from the very beginning.
\n\n\n\n![\"\"](\"/media/server-driven-ui.005-1024x576.jpeg\")
This screen from Primephonic shows a Composer page. It is build up out of several components.
At the top is an Artist header, there are two section headers, three detail buttons that link to other pages and a couple of paragraphs of text.
The order of these components, as well their content, are all decided by the server. So if we want to make a change, and show some albums, instead of biography. We can make that change on the server, without needing to release new versions of the client apps.
\n\n\n\n![\"\"](\"/media/server-driven-ui.006-1024x576.jpeg\")
This is not a new idea. Here are just a few examples of other applications of the same concept:
\n\n\n\nLet\u2019s explore Server Driven UI by building some components. We start small, with a UITableViewCell.
\n\n\n\n![\"\"](\"/media/server-driven-ui.013-1024x576.jpeg\")
This cell shows a single work by Beethoven. This looks simple, but of course there\u2019s more to it than that.
\n\n\n\nWhen looking at the domain model, we see that there\u2019s a ton of details. For each work there\u2019s a separate title, number, key, alternative title, opus number, genre, period and some translations.
\n\n\n\n![\"\"](\"/media/server-driven-ui.014-1024x576.jpeg\")
This domain model lives on the server. In some database somewhere, there are a bunch of fields for this record that contains all this rich information.
What part of all this data do we send to the client? Do we want to send the whole object? Including the fields that aren\u2019t needed? Who does the logic, who decides that the key should be in the top line, and the opus number in the second line?
In a Server Driven UI this is pretty straight forward. Everything is done on the server. The server does all the formatting and simply sends the results to the client.
\n\n\n\n{\n \"title\": \"Piano Sonata No.14 in C# minor\",\n \"subtitle\": \"Op. 27/2 \u2022 \u201cMoonlight\u201d\"\n}This is all the JSON that\u2019s send to the app. A title and a subtitle. Because that\u2019s all that\u2019s needed to implement the design as shown.
\n\n\n\n![\"\"](\"/media/server-driven-ui.017-1024x576.jpeg\")
Obviously, in a real world app, there\u2019s more variations. In certain contexts we may want to include the composer name. Or show the number of recordings that we have for this particular work.
Again, we can do all this in a server driven way. The JSON has a bunch of extra fields, all of which are optional. If the field isn\u2019t included in the JSON, it isn\u2019t shown in the table view cell. It is the server that decides which field is filled when and with what content.
{\n \"type\": \"detailRow\",\n \"addition\": \"Ludwig van Beethoven\",\n \"title\": \"Piano Sonata No.14 in C# minor\",\n \"subtitle\": \"Op. 27/2 \u2022 \u201cMoonlight\u201d\",\n \"disclosureText\": \"873\"\n}![\"\"](\"/media/server-driven-ui.019-1024x576.jpeg\")
Let\u2019s look at a different example, a table view cell that shows an artwork. Again, all variations of this cell are modeled in JSON. There\u2019s a bunch of different fields that are all optional.
\n\n\n\nWhat\u2019s interesting here is that the format of the JSON was very much influenced by the interaction designs for the app. When developing this app, a trio of a designer, a backend engineer, and an app developer together talked through all variations that could occur and designed the visuals and API simultaneously.
\n\n\n\n{\n \"type\": \"artworkRow\",\n \"image\": { \"url\": \"...\" },\n \"addition\": null,\n \"title\": \"Berliner Philharmonic, H...\",\n \"subtitle\": null,\n \"description\": \"1980 \u2022 30 tracks \u2022 2h 8m\"\n}For a final component, let\u2019s look at something more complex. This is a carousel, it lists the top composers in order of popularity.
\n\n\n\n![\"\"](\"/media/server-driven-ui.021-1024x576.jpeg\")
We implemented this as another table view cell, but this one contains a UICollectionView.
Looking at the JSON for this, we see this component is of type carousel. It includes the item type, so we know for the collection view which collection view cells have to be dequeued.
The items field holds an array of items for each composer.
Again, the JSON model is pretty straightforward, an image and a title. That\u2019s all there is to display this cell.
\n\n\n\n{\n \"type\": \"carousel\",\n \"itemType\": \"artist\",\n \"items\": [\n {\n \"title\": \"Beethoven\",\n \"image\": { \"url\": \"...\" }\n },\n ...\n ]\n}Taking it all together, let\u2019s look again at this Composer page.
\n\n\n\n![\"\"](\"/media/server-driven-ui.023-1024x576.jpeg\")
To render this page, the app needs to do 1 single API call to the backend. That API call returns all data for this single screen at once, as a list of components.
\n\n\n\n{\n \"type\": \"componentScreen\",\n \"title\": \"Leonard Bernstein\",\n \"header\": {\n \"image\": { \"url\": \"...\" },\n \"title\": \"Leonard Bernstein\",\n },\n \"sections\": [\n {\n \"heading\": {\n \"title\": \"Popular Works\",\n \"button\": { \"title\": \"Show all\", ...}\n },\n \"components\": [\n {\n \"type\": \"detailRow\",\n \"title\": \"West Side Story\",\n \"disclosureText\": \"258\",\n },\n {\n \"type\": \"detailRow\",\n \"title\": \"Candide\",\n \"disclosureText\": \"116\",\n },\n {\n \"type\": \"detailRow\",\n \"title\": \"Symphonic Dances\",\n \"disclosureText\": \"70\",\n }\n ]\n },\n {\n \"heading\": {\n \"title\": \"Biography\",\n },\n \"components\": [\n {\n \"type\": \"text\",\n \"paragraphs\": \"Leonard Bernstein was an American pianist...\",\n }\n ]\n }\n }\n ]\n}So going from the top, we see the type of the page, a title, and a header. And then a list of sections, each section consisting of a list components.
\n\n\n\nThis whole page is implemented as UITableViewController. And each component implemented as a table view cell. Every row in the table renders itself based purely on the data contained in the JSON.
\n\n\n\nIn fact there is is no special logic in the app for the composer page. This could just as well be a work or an album page. All logic to distinguish between those domain objects lives on the server. The app knowns nothing about that.
\n\n\n\nA topic that comes up quite a lot when talking about an app whose data comes from a server is \u201cNavigation\u201d.
When do we load the data that is needed?
![\"\"](\"/media/server-driven-ui.026-1024x576.jpeg\")
These are two screen from the app, the first shows a list of composers, the second a single composer. But how do we get from the first screen to the second screen?
\n\n\n\nGiven that each screen is one API call, you might think of two approaches:
\n\n\n\nWe didn\u2019t like either of these approaches; We don\u2019t want to have the \u201cwebbrowser\u201d effect, where each link sends you to a white screen that slowly loads. But we also didn\u2019t want taps to be slow, where you have to wait for an API call to return before navigation starts.
\n\n\n\nSo instead, we include the header of the second screen, as part of the link on the first screen.
\n\n\n\n![\"\"](\"/media/server-driven-ui.029-1024x576.jpeg\")
So there are in fact three states that we have to deal with.:
\n\n\n\nThe first screen that contains a link, which includes the header for the second screen.
When we tap that item, we immediately push the second viewcontroller.
That second view controller is in a loading state, that already shows the big header, with a loader animation below.
And the finally, when the API call returns, we fade in all data.
Let\u2019s take a deeper look at the JSON for the Mozart item in the Composers section.
\n\n\n\n{\n \"title\": \"Mozart\",\n \"image\": { \"url\": \"...\" },\n \"action\": {\n \"type\": \"componentScreen\",\n \"url\": \"/query/view/artist/wolfgang-amadeus-mozart-1756\",\n \"title\": \"Wolfgang Amadeus Mozart\",\n \"header\": {\n \"type\": \"artist\",\n \"image\": {\n \"url\": \"...\",\n \"lowresUrl\": \"...\"\n },\n \"title\": \"Wolfgang Amadeus Mozart\",\n \"subtitle\": \"Composer 1756 \u2013 1791\"\n }\n }\n}There is the title and the image fields we saw before, but this item also has a tap action.
That action, already contains the type of the target page. So that we know what view controller to load. It also contains the URL for the API call and a title and a header.
The header is the exact same header that is part of the components on the next API call.
It also contains a title, subtitle and an image.
One interesting aspect of this image, it doesn\u2019t just contain an url field. There\u2019s also a lowresUrl field. That low res image can be used as a placeholder, while the larger image is being loaded. If that image happens to be in the HTTP cache, it is used.
And in fact, that image is very often in the cache, because the low res url is the same url as was used for the small image in the carousel on the previous page.
So in practice, when tapping items in a carousel, we see a nice push animation to a new viewcontroller. Where the top half of the screen is already filled with a header including the background image, while the bottom halve is being loaded.
\n\n\n\nIn general, we are quite happy with this form of navigation. It takes some work on the server, to be able to generate the exact type of header that is also generated when requesting the target URL. But once that\u2019s implemented, the result looks quite nice.
Obviously, it\u2019s not as nice as it would have been had we not have to do the API call. But this is a good middle ground, that works well in practice.
The most obvious action you might expect in an app like this is playing music. So when we tap the first track in this list, the miniplayer pops up, and music starts playing.
\n\n\n\nHow does this work with our Server Driven UI?
\n\n\n\n![\"\"](\"/media/server-driven-ui.043-1024x576.jpeg\")
So a track is a type of component which includes a title, subtitle and a duration. And similar to the navigation example, this also includes an action.
However this action is of type \u201cplay\u201d and it contains all data needed to start playing music.
The tracksMetadataUrl will be loaded asynchronously, to get all data needed to play all the items in the queue. But in the mean time, similar to the header for navigation, this action also includes the startTrack object. So that the player can start playing music as fast as possible, without having to wait for the metadata to be loaded.
{\n \"type\": \"track\",\n \"title\": \"Beginning and Ending\",\n \"subtitle\": \"Max Richter\",\n \"duration\": \"4:54\",\n \"action\": {\n \"type\": \"play\",\n \"tracksMetadataUrl\": \"/query/view/album/886448177210/tracks\",\n \"startIndex\": 0,\n \"startTrack\": {\n \"id\": \"886448177210-0\",\n \"md5\": \"073629779deddb06a14cdb559da7a62d\"\n }\n }\n}![\"\"](\"/media/server-driven-ui.046-1-1024x576.jpeg\")
A different type of actions are what we call \u201cremote command\u201d actions. These we can see in the menu in top right. The JSON for this menu shows a list of actions, each of these actions has a URL to call, and a payload to send back as the body of a HTTP POST.
\n\n\n\n{\n \"secondaryButtons\": [\n {\n \"action\": {\n \"type\": \"command\",\n \"url\": \"/command/endpoint?path=favorite_playlist\"\n \"payload\": \"...\"\n },\n \"title\": \"Add playlist to favorites\"\n },\n ...\n ]\n}![\"\"](\"/media/server-driven-ui.049-1-1024x576.jpeg\")
When we tap the top button \u201cAdd playlist to favourites\u201d.
We see a loader while the API call is happening, when it completes we see \u201cDONE\u201d and the page behind it is refreshed.
If we then open the menu again, we see that it now contains an entry to remove the playlist from favourites.
It\u2019s worth noting here that everything we saw here was very generic. In fact when we started implementing favouriting, this was the first version, and it was completely implemented on the backend. We build and shipped the first version of this feature without doing any work on the clients. Later though, we made it better.
\n\n\n\n![\"\"](\"/media/server-driven-ui.050-1024x576.jpeg\")
Here\u2019s a second type of response a server can send. Instead of just showing a big \u201cDONE\u201d, the server can request input, from either a multiple choice list, or, like in this case, a piece of text. Here we see part of the flow of creating and editing playlists, and again, this is all orchestrated by the server.
\n\n\n\nNow, there are some things that can\u2019t be implemented by the server. For some things, we need the client.
\n\n\n\n![\"\"](\"/media/server-driven-ui.052-1024x576.jpeg\")
{\n ...\n \"secondaryButtons\": [ ... ],\n \"share\": {\n \"title\": \"Check out \u201cEpisode 1: Baroque Era\u201c on Primephonic\",\n \"url\": \"https://play.primephonic.com/playlist/AEl7xsGhQegEhOoyY6cge\"\n }\n}Here we see a share button in the top right, when we tap that the system share sheet pops up. For this we need client side logic. So what the server sends us is fairly compact. The server decides the text that is shared, and includes the Universal URL. But it\u2019s up to all the clients to decided what to do with this. In the iOS example, we insert a share sheet button in the navigation bar. We also use this URL for Handoff between different Apple devices.
\n\n\n\n![\"\"](\"/media/server-driven-ui.053-1024x576.jpeg\")
And finally, in case you were worried we left favouriting in that ugly menu from before: of course not. When we had some time on the client side, we went in and wrote special case code to intercept the favourite item. Instead of showing it in the menu, we create a nice button with a heart icon.
\n\n\n\nIn theory, when you press it, we can show a nice animation and proactively select the item. The API call to favourite the item can then be done in the background. We then of course need to also implement all the logic for handling all edge cases, like network errors or if the server returns an error, we need to unselect the item again.
\n\n\n\nUnfortunately, Primephonic isn\u2019t there quite yet. Currently when you press the button, there\u2019s still a full screen spinner, but at least the button looks nice already!
\n\n\n\nHere are some specifics related to the API, and how we integrated that in the app.
\n\n\n\n![\"\"](\"/media/server-driven-ui.056-1024x576.jpeg\")
As you can see, we include versioning in our API. And in the 2 years the app has been live, we\u2019ve already created 15 versions. But, that\u2019s not a big issue. Versions are cheap.
\n\n\n\nWe create a new version in this API whenever we add a new component type that the existing clients don\u2019t know about. So when a requests comes in, the server looks at the version number of the request, and only returns the component types that that client supports.
\n\n\n\nIf an older client sends a request, the server has to decide what to do as a fallback for a certain component. Maybe there\u2019s a nice new carousel, but the client doesn\u2019t support that yet. Then the server can send back an old boring list of items. Or simply skip the item, for that old client.
\n\n\n\nOn the server there\u2019s a single codebase that supports all versions. The server maintains has a big list that shows which API version supports which component types.
\n\n\n\nShould it ever become too much of a hassle to maintain all these versions, and statistics show a certain version is rarely used anymore. Then the server can decide to no longer support that version and send back a generic error message, using the \u201ctext\u201d component type that already existed in version 1.
\n\n\n\n![\"\"](\"/media/server-driven-ui.057-1024x576.jpeg\")
Again, this screen is implemented as a UITableViewController. It uses a diffable data source to animate between changes when reloading after performing remote command.
\n\n\n\nThe clients and server also make use of an HTTP Etag to indicate that there are no changes, so we don\u2019t need to animate anything.
The same goes for a client side triggered cancellation.
struct Section: Decodable {\n let heading: Heading?\n let components: [ValueOrDecodingError<Component>]\n}\n\n\nenum Component {\n case carousel(Carousel)\n case detailRow(DetailRow)\n ...\n}\n\n\nstruct DetailRow: Decodable {\n let title: String\n let subtitle: String?\n let disclosureText: String?\n let primaryAction: Action?\n let deleteAction: Action?\n}JSON parsing is all implemented using Swift\u2019s Codable. We create dedicated structs that directly match with the JSON that the server returns.
Sometimes we need domain objects to sit between the API models and the views. In that case we map from these API models to separate domain models.
I should note that while the server needs to support multiple API versions at the same time, for the clients its a lot easier. It only needs to support 1 API version. So we can even remove old component types in newer API versions, and just throw away that code from the clients. The server isn\u2019t so lucky.
\n\n\n\nOne thing you may have noticed is the ValueOrDecodingError type in the components array of the top Section struct. This is there to protect against programmer error.
\n\n\n\nIn theory the server should never send something to a client that a client doesn\u2019t support. But in practice, programmers are people, and people make mistakes.
\n\n\n\npublic enum ValueOrDecodingError {\n case value(Wrapped)\n case error(DecodingError)\n}So the ValueOrDecodingError exists as a safeguard. It is a generic enum, that either wraps a single value, or it contains an error.
\n\n\n\nThe Decodable implementation for this types tries to decode a value of the generic Wrapped type. If it succeeds, it returns that value, if it fails, it returns the decode error.
\n\n\n\nstruct Menu: Decodable {\n let buttons: [ValueOrDecodingError]\n}What that gives us in practice is that parsing doesn\u2019t stop when there\u2019s an error in our JSON. In this example, when we parse this menu, if the JSON array contains 4 objects, but one of those isn\u2019t actually a button, we still get the other buttons.
\n\n\n\nThe array will contain 3 buttons, and 1 error. We can then decide what to do with that error. In the case of Primephonic, we mostly log the error and skip the item, still showing the rest.
\n\n\n\nIn practice, this has saved us a couple of times, when someone made a mistake that wasn\u2019t caught in testing.
\n\n\n\nLibrary: https://github.com/tomlokhorst/Statham
\n\n\n\n![\"\"](\"/media/server-driven-ui.061-1024x576.jpeg\")
Finally, one interesting aspect of this Server Driven UI, is that we can even use this for our offline experience.
\n\n\n\nWhen you\u2019re online, the app also downloads one special page, that contains a component screen for the offline version of the app.
\n\n\n\nThen, when you’re offline, you can use that version to browse around your offline downloaded music.
\n\n\n\nFor the past year, I haven\u2019t worked on Primephonic. So I asked the one of the current developers what their experiences were with Server Driven UI.
\n\n\n\nAnd one example that came up was the Offline experience.
\n\n\n\n![\"\"](\"/media/server-driven-ui.064-1024x576.jpeg\")
He said the single JSON response for the offline version became too large. While the initial development went very fast, because of the reuse of components.
\n\n\n\nThey\u2019ve since switched back to a more traditional API.
\n\n\n\nFor the offline page we needed to send the JSON for everything, not just the first page, but any page you might navigate to. And it turned out that some users had 20 megabyte big offline JSONs that needed to be synced all the time.
\n\n\n\nSo this is an example were the Server Driven UI with big JSON responses didn\u2019t work so well.
\n\n\n\n![\"\"](\"/media/server-driven-ui.065-1024x576.jpeg\")
Two other things in this app that weren\u2019t implemented using Server Driven UI are the music player itself and the subscription flow. These are both deep native OS integrations.
\n\n\n\nWhen you\u2019re playing music, it needs to integrate with the Now Playing screen on your iPhone, it needs to respond to remote control commands from your AirPods. And you can also control playback from your Apple Watch or CarPlay.
\n\n\n\nThe subscription flow is an In-App Purchase, so that\u2019s also very specific logic.
\n\n\n\n![\"\"](\"/media/server-driven-ui.066-1024x576.jpeg\")
And finally, here\u2019s an example of a completely different app, as an example of when not to use Server Driven UI.
\n\n\n\nThis is another app I\u2019ve also worked on, the Rijksmuseum app.
It allows you to walk tours in the museum where you can listen to audio descriptions of artworks.
In this app almost all the logic happens in the client. One big JSON file is download that contains all the information about tours. And the client does all sorts of Bluetooth logic to show you what room you\u2019re in.
\n\n\n\nFor this type of app, a Server Driven UI isn\u2019t appropriate, even though there is a server that maintains all the data about the tours in the museum.
\n\n\n\nServer Driven UI can be a great setup for certain types of applications (or parts of applications). If you have a lot of domain objects, but ultimately a relatively simple user interface, an approach where you deal with all the domain complexity on the server can be quite helpful.
\n\n\n\nI think there are two extremes; On one side you sent complete domain objects to the client, on the other side, you send only UI instructions to the client (think of HTML, or more extreme an image or PDF). There\u2019s probably a gradient between these two extremes, and Server Driven UI lies somewhere in the middle.
\n\n\n\nWith Primephonic, we found that the browsing experience through a rich database of classical music could very well be implemented using Server Driven UI. On the other hand, the actual Music Player was best implemented fully in the native client app.
\n\n\n\nInterested in Classical Music? Check out Primephonic!
\n", "date_published": "2020-07-22T20:04:00+02:00", "date_modified": "2023-04-09T18:48:06+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2020/07/cloudstorage-property-wrapper", "url": "https://tom.lokhorst.eu/2020/07/cloudstorage-property-wrapper", "title": "@CloudStorage property wrapper", "content_html": "I wrote a Swift library to help with prototyping (haven’t used it yet in production apps).
\nCloudStorage is property wrapper that will save values in iCloud key-value storage. These values are persisted across app restarts and will sync between different devices that are signed into the same iCloud account. This property wrapper is similar to AppStorage and SceneStorage, two new types Apple introduced with iOS 14.
\nThe basic API is the same as for AppStorage; add @CloudStorage(\"someName\") in front of a property, to save the value to iCloud key-value storage.
Make sure you enable the “key-value storage” service in the iCloud capability. See Apple’s documenation.
\n\n@CloudStorage(\"readyForAction\") var readyForAction: Bool = false\n@CloudStorage(\"numberOfItems\") var numberOfItems: Int = 0\n@CloudStorage(\"orientation\") var orientation: String?\nSee also the example app in the repository.
\nThe same caveats apply as with key-value storage itself:
\n\nKey-value storage is for discrete values such as preferences, settings, and simple app state.
\nUse iCloud key-value storage for small amounts of data: stocks or weather information, locations, bookmarks, a recent documents list, settings and preferences, and simple game state. Every app submitted to the App Store or Mac App Store should take advantage of key-value storage.
From Apple’s documentation on choosing the proper iCloud Storage API.
\nIn general, key-value storage is not meant as a general purpose syncing service. If you need any advanced capabilities to prevent data loss, consider using CloudKit instead.
\nCheck out the CloudStorage repository.
\n", "date_published": "2020-07-20T11:38:00+02:00", "date_modified": "2020-07-21T13:51:56+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2020/06/my-wish-for-watchos-cycling-support", "url": "https://tom.lokhorst.eu/2020/06/my-wish-for-watchos-cycling-support", "title": "My wish for watchOS: Dutch-style Cycling support", "content_html": "\n![\"\"](\"/media/Outdoor-Cycle-1.png\")
Currently, watchOS has a workout called \u201cOutdoor Cycle\u201d, the icon shows a person on a racing bicycle. But that is not what cycling means, for millions of people who use a utility bicycle for daily transportation.
\n\n\n\nInstead of specific activity, that some people do, some of the time. Cycling can also be a boring part of everyday life, that everyone does, all of the time.
\n\n\n\nHere I\u2019m going to make some assumptions and generalisations about places I don’t live… When I think of cycling in some other places, like say California, I think of something like this:
\n\n\n\n![\"\"](\"/media/us-bicycle-example1-1024x669.jpg\")
![\"\"](\"/media/us-bicycle-example2.jpg\")
Here we see people, hunched over on racing or road bikes. They go fast, wear special protective clothing and are are really working out. More importantly, culturally these people are doing something abnormal, in the sense that cycling is not the norm, most people don\u2019t cycle regularly.
\n\n\n\nIn contrast, this is a typical Dutch view of cycling:
\n\n\n\n![\"\"](\"/media/cycling-nl-example1.jpg\")
![\"\"](\"/media/cycling-nl-example2.jpg\")
![\"\"](\"/media/cycling-nl-example3.jpg\")
In The Netherlands, cycling is a common mode of transport. 27% of all trips are made by bicycle. In Amsterdam, a third of morning commutes are made by bicycle, making it the most popular form of transport (above walking and cars). At first glance you can see the differences: people sit upright, drive slowly, and they are wearing ordinary clothing. The bicycles themselves are also different; They are relatively cheap, have a kickstand, a chain guard and angled-back handlebars. They also include one or two luggage carriers.
\n\n\n\nSide note; It\u2019s not that the other type of bicycle doesn\u2019t exist in The Netherlands. We too have people who (in the weekends), put on a helmet, dress up in lycra, and take out their other sporting bicycle. To do competitive racing, or mountain biking in the woods. But those are recreational sports, not day-to-day transport.
\n\n\n\nI would like it if watchOS 7 added an additional option. To support this normal, everyday, utility cycling. It seems a bit weird to call this a \u201cworkout\u201d, but hey \u201coutdoor walking\u201d is also in there, so what the heck. I even designed an icon for this:
\n\n\n\n![\"\"](\"/media/Utility-Cycle-Mockup-EN.png\")
In a similar way to Outdoor walking, this activity should be automatically detected and activated. This could be used to more accurately track activity when commuting to work, taking the kids to school or grocery shopping. And while you\u2019re at it Apple, please also add the cycling modality to Apple Maps!
\n\n\n\nPS: For those unfamiliar, here’s a little mood impression of what cycling in The Netherlands looks like:
\n\n(Also, do check out the rest of the rest of BicycleDutch channel on YouTube. It’s great!)
\n", "date_published": "2020-06-02T10:20:44+02:00", "date_modified": "2020-06-03T14:11:10+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2019/07/every-two-years-apple-increases-software-support-by-a-year", "url": "https://tom.lokhorst.eu/2019/07/every-two-years-apple-increases-software-support-by-a-year", "title": "Every two years, Apple increases software support by a year", "content_html": "Over the last 12 years, a pattern has emerged: Every two years Apple has adds an extra year of iOS support to its System-on-chips (SoCs).
\nThe original iPhone and iPhone 3G both had three years of software updates. The iPhone 3GS and iPhone 4 had four years of updates, and so on.
\nThis diagram visualises that pattern:
\n![\"iOS](\"/media/ios_versions_per_soc@2x.png\" "\\"iOS")
The coloured lines indicate iOS support a specific SoC. The grey line indicates when devices with this SoC were sold.
\nNote that this diagram specifically plots SoCs, and not iPhone releases. The same A-series SoCs are used across iPhones, iPads and iPod touches. I’ve merged the releases of several of these devices to create this diagram.
\nShould this trend continue in the future, the A8 will be supported for 6 years. The A9/A10 for 7 years, and the A11/A12 for 8 years.
\nThat means the iPhone XS released in September 2018, which runs the A12 Bionic, would get updates until 2025, with iOS 19.
\nAgain, the above diagram refers to SoCs in general, and not iPhones, because if we plot that, there’s an exception for the iPhone 6.
\n![\"iOS](\"/media/ios_versions_per_iphone@2x.png\" "\\"iOS")
The coloured lines indicate support iOS support for an iPhone. The grey line indicates when the iPhone sold.
\nThe iPhone 6 was released in September 2014 and was for sale until March 2017.
\nIn September 2019, when iOS 13 comes out, the iPhone 6 will no longer be supported. This is unfortunate because a lot of users are still using iPhone 6 devices. At Q42 we see it is the 6th most popular iPhone with 7% usage, more popular than the iPhone SE or iPhone XR.
\nAlthough support for the iPhone 6 (and iPod touch 6th gen) is being dropped, the iPad Air 2 and iPad mini 4 of the same generation are still supported. The iPad mini 4 uses the same A8 SoC as the iPhone 6.
\nA possible explanation for why it is being dropped might be the size of the RAM. iPhone 6 uses an A8 SoC, but it only has 1GB of RAM. The iPads both have 2GB of RAM.
\nEvery device supported by iOS 13, has at least 2GB of RAM.
\n\nIt is impossible to predict the future, but I don’t think this “RAM filter” will occur again soon.
\nThe next obvious step would be some future version of iOS that only supports 3GB RAM. But that would cut product lines in half. iPhone 7 and 8 both have 2GB or RAM, but the iPhone 7 Plus and 8 Plus use 3 GB.
\nThe step after that is 4GB as a minimum, but that includes some very recent devices. The iPhone XR (September 2018) and iPad Air 3 (March 2019) both ship with 3GB of RAM.
\nMy assumption is that, for the coming years, device deprecations will again be solely based on SoC.
\nWill this trend of adding a support year continue indefinitely? If not, when will it stop? Will there be another iPhone 6-style hiccup? Who knows!
\nI can’t wait for WWDC 2020, to see what iOS 14 brings!
\nAll data about SoCs and release years are taken from Wikipedia. This chart lists all iOS-like devices from the past 12 years.
\n", "date_published": "2019-07-15T12:00:25+02:00", "date_modified": "2019-09-16T10:01:18+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2018/12/hacking-marzipan-running-ios-apps-on-mac-talk", "url": "https://tom.lokhorst.eu/2018/12/hacking-marzipan-running-ios-apps-on-mac-talk", "title": "Hacking “Marzipan” – Running iOS apps on Mac [talk]", "content_html": "A recording from my talk at the Do iOS conference last month.
\n\n\nAt WWDC 2018 Apple announced that in the future it will become possible to run iOS apps on macOS. Rumours about this first appeared in December 2017 and was believed to be codenamed Marzipan. Although there is no official API or support for it yet in this talk Tom Lokhorst shows how he experimented with Marzipan and what he learned.
\n
The example project used in the talk is available on GitHub: MarzipanDemoApp.
\n", "date_published": "2018-12-10T01:10:29+02:00", "date_modified": "2020-07-22T12:34:20+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2018/06/machine-learning-ar-at-the-rijksmuseum", "url": "https://tom.lokhorst.eu/2018/06/machine-learning-ar-at-the-rijksmuseum", "title": "Machine Learning + AR at the Rijksmuseum", "content_html": "For the past four months Daniello, an intern at Q42, has worked on training a machine learning model to recognise artworks in the Rijksmuseum. Once recognised, the paintings are located in the AR camera feed and augmented using ARKit.
\nThis week at WWDC, Apple announced CreateML and ARKit 2. Those two solutions combined may make this process a lot easier, but nevertheless, it’s really cool to see what Daniello build:
\n\nArt recogniser Rijksmuseum from Q42.
\n", "date_published": "2018-06-07T21:59:03+02:00", "date_modified": "2018-06-07T21:59:03+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2018/03/rijksmuseum-artviewer-talk", "url": "https://tom.lokhorst.eu/2018/03/rijksmuseum-artviewer-talk", "title": "Rijksmuseum ArtViewer [talk]", "content_html": "A recording from my talk at CocoaHeadsNL last month
\n\n\n\nTom Lokhorst from Q42 talks about how they developed the ArtViewer for the Rijksmuseum app. This viewer is a highly optimised image viewer to display very large images. It efficiently uses caching and tiling to save memory and bandwidth.
\n
Rijksmuseum ArtViewer, Tom Lokhorst from CocoaHeadsNL.
\nSee the Rijksmuseum app in the App Store.
\n", "date_published": "2018-03-08T15:02:48+02:00", "date_modified": "2018-03-18T15:08:53+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2018/02/leaky-abstractions-in-swift-with-dispatchqueue", "url": "https://tom.lokhorst.eu/2018/02/leaky-abstractions-in-swift-with-dispatchqueue", "title": "Leaky abstractions in Swift with DispatchQueue", "content_html": "\nAt Q42 we have some apps with very occasional weird multi-threading issues. After a bunch of debugging Mathijs Kadijk and I figured out it had something to do with DispatchSpecificKey. This post details what we found out.
\nPop quiz! What do you think this prints?
\n![chart](\"/media/ios_versions_per_device_july_2019@2x.png\"){kind=link}
\nwhile true {\n let key = DispatchSpecificKey<Int>()\n\n if let value = DispatchQueue.main.getSpecific(key: key) {\n print(\"ERR \\(value)\")\n exit(1)\n }\n else {\n DispatchQueue.main.setSpecific(key: key, value: 42)\n print(\"OK\")\n sleep(1)\n }\n}\nAnswer: This does not print a infinite stream of OKs every second, as I would have thought. Instead, it stops after three iterations of the loop:
\n\nOK\nOK\nERR 42\nProgram ended with exit code: 1\nThe output changes a bit each time I run the program. Sometimes it makes it to three or four OKs, but often it only prints one OK and then stops with an ERR.
\nMy question after seeing this behaviour: Wut? How can two distinct keys result in the same value?!?
\n\nIt turns out these (woefully underdocumented) Swift APIs are wrappers around C APIs. The code for this is all open source, see Queue.swift. The underlying C APIs are better documented and give some insight into how this all works internally:
\ndispatch_queue_set_specificdispatch_queue_get_specificThe documentation for dispatch_queue_set_specific explains how the key is just a pointer to something, it doesn’t really matter what it’s pointing to.
\n\nKeys are only compared as pointers and are never dereferenced. Thus, you can use a pointer to a static variable for a specific subsystem or any other value that allows you to identify the value uniquely.\n
For this reason, the Swift implementation of DispatchSpecificKey is very simple:
\npublic final class DispatchSpecificKey<T> {\n\tpublic init() {}\n}\nThe initialised object is only used to get a pointer value that can be passed to the dispatch_queue_set_specific function. This pointer should of course be unique (hint: it is not).
Suspecting this behaviour has something to do with the pointer, lets add a print statement to see what the pointer value is:
\n\nlet p = Unmanaged.passUnretained(key).toOpaque()\nprint(\"Pointer: \\(p)\")\nThis resulted in the following output:
\n\nPointer: 0x000000010120b590\nOK\nPointer: 0x000000010104ab00\nOK\nPointer: 0x000000010120b590\nERR 42\nProgram ended with exit code: 1\nFinally, this the explains the behaviour we’re seeing; Different instances of DispatchSpecificKey share the same pointer!
\nPresumably ARC cleans up the key variable after we’re no longer using it and in a next iteration of the loop, the same memory location is reused again to store a new instance of DispatchSpecificKey.
There are different solutions to fix this unexpected behaviour. One is to simply keep an array of each DispatchSpecificKey that gets created, that way no two DispatchSpecificKeys get assigned to the same memory location.
\nIn my own code, I happened to have the key be a member of an object. The solution was to add a deinitializer to the object:
\n\nclass MyObject {\n let key = DispatchSpecificKey<Int>()\n\n deinit {\n DispatchQueue.main.setSpecific(key: key, value: nil)\n }\n}\nA more general solution would be if DispatchSpecificKey were to be updated to clean up after itself:
\n\npublic final class DispatchSpecificKey<T> {\n public init() {}\n\n // Is it OK to keep strong references to queues?\n internal var queues: [DispatchQueue] = []\n\n deinit {\n for queue in queues {\n queue.setSpecific(key: self, value: nil)\n }\n }\n}\nIt took us a lot of debugging to finally narrow down the source of our bug to this reusing of the same memory address by two distinct objects. Normally in Swift code this wouldn’t be a problem, but because the underlying C API uses just pointers to compare for equality, this suddenly matters.
\nFor the C code, it is arguable that the programmer should be responsible for cleaning up after they’re done with a C “dispatch specific key”. They should call dispatch_queue_set_specific with a nil value themselves.
But for the Swift code; The DispatchSpecificKey class really implies programmers shouldn’t have to know about the pointer internals of the C API. So in my opinion that class should have the cleanup code build-in.
\n", "date_published": "2018-02-09T12:13:58+02:00", "date_modified": "2019-02-22T23:18:04+02:00", "author": { "name": "Tom Lokhorst" } }, { "id": "https://tom.lokhorst.eu/2017/10/cocoaheadsnl-talk-reactive-uis", "url": "https://tom.lokhorst.eu/2017/10/cocoaheadsnl-talk-reactive-uis", "title": "Building Reactive User Interfaces [talk]", "content_html": "A recording from my talk at CocoaHeadsNL last month:
\n\nTom Lokhorst – Building Reactive User Interfaces from CocoaHeadsNL.
\nMentioned in the talk, the work-in-progress Bindable library.
\n", "date_published": "2017-10-11T12:18:42+02:00", "date_modified": "2018-03-17T13:36:13+02:00", "author": { "name": "Tom Lokhorst" } } ] }