I was really impressed with Kate Castellano’s talk on day two of UIKonf 2019. She explained how Clue was using server generated JSON to configure native UI to provide a highly flexible experience to their users. If you haven’t seen her talk, you should take a moment to watch it.
She gave a follow up talk at Pragma Conf later in 2019 with even more information including a demo of adding a video component to the templated system. I’ve been mulling over how this technique changes building native apps for a while and her talk gave me a lot to think about.
When I led the front-end team at the Apple Online Store, I tried to move more and more of the logic into the Javascript on the visitor’s browser. This worked well enough for components like the Valentine’s Day custom engraving feature, but we discovered running a lot of Javascript client-side was slow during the checkout process and unbearably — sale preventingly — slow on slower browsers. Of course, all this was before the shadow DOM made what we were trying to do so much faster and more efficient. Everyone’s using React or Vue or something client-side these days.
Years later as the primary developer working on the iOS versions of iTunes Connect and App Store Connect I struggled with this same balance of where the code should execute. Except this time I argued for the intelligence to be on the server; I’d learnt my lesson. The client didn’t have any place interpretting the business logic and rules that might change at — what seemed to us — a moment’s notice. Far better for the client to receive an already rendered value than to attempt to concatenate an application’s platform, bundle version, and status together to form a string like “iOS 2020.3.13 Pending”. The more the client served to simply display data sent from the server, the more I could focus on building better infrastructure which would allow us to deploy more features1.
The natural extension of this approach is a server-defined user interface like Kate describes in her UIKonf & Pragma Conf talks. I think building the UI from the server is particularly appropriate when an application is driven by campaigns or other timely information (as is the case in Kate’s examples). When you think about it, most of our applications are all about timely information unless you’re building a reference library. Giving your marketing and product teams greater control over how the application changes may seem like giving up that control, but it really gives you the flexibility to focus on what you do best: building great software.
I really like this idea and would love to explore it a bit. I’ve got the bare beginnings of an idea for a sample app that I’m going to bounce off a few folks. This might give me the opportunity to expore a couple other technologies I’ve been curious about like Sign in with Apple and CloudKit.
-
I know it didn’t seem like either app iterated quickly on features. I had a wish list as long as my arm of features I wanted to implement and our design team had another list they wanted to jump on, but for reasons we could just never get them scheduled. Let’s say it was a frustrating job. ↩︎