Marzipan: An Engineering Leader's Perspective on Bringing UIKit to the Mac

/

There has been a lot of discussion in the Apple pundit community about running UIKit apps on the Mac (aka Marzipan). A lot of the coverage has been that of the customer's perspective, but thinking about it from Apple's internal perspective is far more interesting. 

I want to first set some context that I think heavily influenced this decision. Over the last several years there have been some thematic concerns from the Apple community. The first is concerns about software quality as classically outlined by Marco Arment's Apple has lost the functional high ground post. Another theme that emerged was that macOS has been neglected as iOS rose to prominence. Additionally, the Mac App Store hasn't seen a lot of love from Apple and  several major and indie developers have pulled their apps due to App Store guidelines. Finally, there has been a theme of worry that the iPad is being neglected. There were signs of hope in iOS 9 and iOS 11 but hasn't seen the annual incremental functionality that the iPhone has seen.

Hire More Developers

I firmly believe that Apple, like most great consumer companies does listen to customer feedback and takes it very seriously. The common answer to solving these problems from the Apple community is to simply throw more engineers at the problem.  You hear: "Apple has $285B, surely they can put more engineers on X."  This is actually quite harder than you think.

The Tim Cook era Apple is all about discipline and math built on top of the Steve Jobs legacy. You can argue qualitatively about how that's going, but by quantitative measures it's hard to argue anything short of very successful. If you layer discipline and math to frame how Apple would solve these problems with management principles it becomes very interesting.

Revenue

In Q2 2018, Apple spent $666M on R&D with $61.1B in revenue.  That equates to 1.09% of revenue being spent on R&D. In Q2 2017, Apple spent $575M on R&D with $52.9B. That also equates to 1.09% of revenue being spent on R&D. From a budget and planning perspective, it's clear that Apple is having budget discipline with growing R&D spend in line with revenue growth. So assume that R&D growth will be capped to staying inline with 1.09% for the foreseeable future.

Next, let's look at how iPhone, iPad and Mac impact company as a percentage of revenue for Q2 2018. Again, they generated $61.1B in revenue. Let's look at the breakdown below:

Product Q218 Revenue $B
iPhone $38.03
iPad $4.11
Mac $5.85
Other Products $3.95
Services $9.19
Apple Q2 2018 revenue by product line

Apple Q2 2018 revenue by product line

Now that we know where revenue is coming from, and we factor in that R&D investment increases in-line with revenue we can make some assumptions. For every 100 engineers that Apple hires, 62 should go to iPhone, 15 to Services, 10 to macOS, 7 to iPad and 6 to Other Products. That seems simple, and given that macOS and iPad get some new resources, surely things will somehow get better... However, this is missing a huge factor: Where growth is coming from.

Growth

Year over Year, Apple generated $8.21B in incremental revenue. The main drivers were iPhone, Services and Other Products. The iPad and Mac drove little to no growth. Below we see the full breakdown:

Product Q218 Growth $B
iPhone $4.75
iPad $0.22
Mac $0.01
Other Products $1.08
Services $2.15
Apple Q2 2018 YoY revenue growth by product line

Apple Q2 2018 YoY revenue growth by product line

Factoring in where growth is coming from we can make some new assumptions. For every 100 engineers that Apple hires, 58 should go to iPhone, 26 to services, 13 to other products, 3 to iPad and 0 to macOS. This seems to be closer to what Apple has been doing the last few years. We have seen solid improvements to iPhone features in iOS. Improvements and new services such as Apple Music, Apple Photos, CloudKit, Messages in the Cloud, etc... Expansion and improvements to the other products such as Apple Watch, AirPods, Apple TV, HomePod, etc... iPad has gotten some love but usually every other year, and gets some halo effect due to iOS being a shared platform across iPhone and iPad. macOS, not a ton of new functionality but existing resources can keep chugging along.

Future Growth

However, we are missing one critical assumption here. Apple has always had a focus on where future revenue growth is coming from. At the most basic level, you can shift more investment to the fastest growing segment if you believe that it will continue or accelerate with investment. In this case, Services and Other Products, which have shown faster progress in the last few years. 

The other option is to create incremental products. The most exciting products at Apple are the ones we know nothing about. It is certain that Apple allocates a percentage of R&D investment to incremental product lines to unlock incremental growth as iPhone growth matures. As a result, the resource mixes above are reallocated. iPhone may be getting more, Services may be getting even more, new product lines are getting resources as well. Project Titan was rumored at one point to have over 1000 employees, and it still hasn't/may never see the light of day. Which illustrates that Apple is willing to make big bets. An example of this is when Steve Jobs delayed Leopard to divert as many engineers as possible to the iPhone.

Talent Availability

Labor market constraints also add considerable challenges in scaling Apple's software capabilities. There are only so many iOS/Mac developers out there that:

  1. Meet the technical requirements to work at Apple (Objective-C/Swift, UIKit, AppKit, etc...)
  2. Are willing to live where Apple does business
  3. Have domain expertise (Audio, Video, AR, Machine Learning, etc...)
  4. Willing to abide by Apple's secrecy
  5. Willing to forfeit side-projects

Even if Tim Cook gave the go ahead to hire as many resources as needed to make the Mac great, the people may not exist. You can only hire and onboard so many new engineers at a time without impacting quality and stressing the broader organization. Product Managers, Product Marketing and other functions that are at the beginning of the product development lifecycle need to be several months ahead in the process.

Combining the factors of revenue mix, current growth rates, where future growth is likely to happen, talent availability and Apple's discipline keeping R&D spend at 1.09% of revenue you have 2 essential levers to pull in the magical software machine to address these concerns.

  1. Re-prioritize
  2. Platform Leverage

Re-prioritize

Apple could divert more resources to the Mac or iPad functionality in iOS, the trade off is stealing resources from future sources of growth. If macOS being behind was only a short-term issue and didn't need ongoing investment it may make sense. However, if it is a long term investment you have to have a degree of confidence that the Mac is a source of future growth on an ongoing basis. All signs point to that not being the case.

Platform Leverage

The other option is how do we get more leverage out of the resources that Apple currently has and get more leverage out of every incremental engineer they hire. This is clearly the strategy Apple is employing here. The basic premise is if Apple can consolidate to a smaller number of software platforms to maintain and enhance, agility and quality improve. The entire ecosystem will benefit as a result.

I'm not saying that Apple will eliminate macOS and have iOS running on MacBooks. This means unifying foundation level technologies across iOS, macOS, watchOS, tvOS, etc... as a first step. Once you complete this process, any incremental functionality introduced spans across all of these platforms.  The QA you do at this level also benefits every experience. You start low in the stack and work your way up to the customer experience over time.

One place Apple has already done this is with the iTunes Store. What started as Music only, then expanded to TV Shows, Movies and eventually the App Stores. It's all sharing the same underlying infrastructure. Apple has invested heavily in modernizing the underlying architecture of the iTunes store, once that process matured they moved to the user experience in 2016/2017.

UIKit to the Mac

So how does the concept of Platform Leverage apply to the UIKit on the Mac? Let's go back to our original statements of what Apple's problems are:

  1. Software Quality
  2. macOS Neglect
  3. Mac App Store Neglect
  4. iPad Neglect

Software Quality

The first step of unifying underlying system frameworks will have a big benefit from a quality perspective. This reduces the number of total frameworks QA needs to test while QA staffing remains equal or grows. This is more total QA attention. The same concept applies from an engineering perspective and a test coverage perspective. Further, by bringing iOS apps to the Mac, first party app quality goes up as well. These apps are used by many more users on iOS, get more engineering attention, and more QA time as well. This increases overall software quality on the Mac. It also reduces the amount of new code they have to write, which does not introduce new defects. As UIKit on Mac matures to its end state, you get even more leverage as you can combine more iOS and macOS resources.

macOS Neglect

If Apple can take existing iOS apps that have more features (or missing from macOS completely) and bring them to macOS, the Mac platform gets feature parity with iOS at a much lower cost.There are also more external developers that currently use UIKit vs AppKit so the opportunity for new macOS apps increases substantially. The barrier to entry is far lower. Additionally, developers that have been nervous about major updates to their Mac software, but have a more modern iOS version can bring a major update to market with less effort. This isn't true for every app, but for most apps that normal people (not geeks) use this is probably the case. Some argue that UIKit apps are not Mac Apps, that is true, Mac Apps as we know them. For the average user, UIKit apps will make the Mac a more accessible platform that is easier to use.

Mac App Store Neglect

The iOS App Store saw a big overhaul in 2017 with iOS 11. The Mac App Store overhaul for Mojave this year is all about platform and resource leverage. The tooling built to do content features in iOS can be leveraged for macOS and increase the quality of the Mac App Store. Apple also gets resource leverage from editorial staff, writing and content attracting users to open the store more frequently. This will increase substantially when 3rd Party UIKit Apps start coming out. An article about a great To Do List app can now be published on both the iOS & Mac App Stores. This, combined with more apps, and getting some famous developers back on the platform make the Mac App Store much more compelling to the average Mac user.

iPad Neglect

The solution to iPad neglect develops over time, but I think the iPad will benefit in a big way. Apple has had issues getting large software vendors to build Pro Apps for the iPad. Opening up UIKit to the Mac will help with that problem over time. Before UIKit comes to the Mac for third party developers, Apple needs to solve how to do multiple windows, shared app instances, menu bars, etc... These features will directly benefit the iPad in the coming years. It'll make app multi-tasking better, drag and drop support better, having 2 windows of an app, etc.. User input device support for the Mac will also benefit the iPad. A bluetooth mouse being the first that comes to mind. Not usable in every app/context, but a text cursor would be huge. For third party developers who have avoided iPad apps due to market size, specifically in the pro market, will have more incentive to come to iPad.

Where is this headed?

My best guess is UIKit on the Mac as presented at WWDC 2018 is in the very early phases. Bringing a small number of UIKit Apps to the Mac in Mojave is more about a proof of technology than anything else. These apps aren't super valuable from a user perspective, but extremely valuable from an engineering perspective. With a fully automated test suite (unit tests, integration tests, UI Automation) you can begin to do the work of unifying the foundation of iOS and macOS and have a ton of visibility on how well you're doing. 

Once you get all foundational frameworks running happily on iOS and MacOS, you then start moving closer to the user experience. Multi-window support, menu bar support, user input devices, drag and drop (which may already be solved) and other features need to be supported. Maybe it gets built into UIKit or maybe it's a new framework. It could be both over time. Regardless, over time we will see more powerful apps come to the iPad and simpler more iOS like apps to the Mac. This will expand the potential market for both iPad and the Mac. More pro users will be able to do their work on the iPad. The touch-input generation will have apps on the Mac that work the way they expect them. This could extend the Mac to another generation of computer users, especially as that generation moves into the work force.

Ultimately I think Apple will come out with a new UI Framework that sits on top of all their OS's but I think that's a few years away. It'll start with UIKit portability on the Mac and over time base functionality for Mac being built into iOS. I expect that to be the short term strategy. Long term, assuming they're serious about Swift, I envision a native Swift UI library with modern design patterns that spans all of their OS's. Including watchOS, tvOS and any future product with a UI.

Finally, you don’t have to agree with how Apple decides to allocate it’s resources, but hopefully this gives you an idea of how resources get allocated in a large company such as Apple.

Developers vs Engineers

/

A great post went around last week that I think everyone should read. There are a couple of great quotes that really capture the attributes that I think make great engineers great.

Understand, at least on some level, the things that you depend on. Own everything. Similarly, if you built it and it’s running in production, it’s on you to support it. Throwing code over the wall is no longer acceptable. When there’s a problem with something you depend on, don’t just throw up your hands and say “not my problem.” Investigate it. If you’re certain it’s a problem in someone else’s system, bring it to them and help root cause it. Provide context. When did it start happening? What were the related events? What were the effects? Don’t just send an error message from the logs.

Owning everything, or controlling your own destiny is so important. We've all worked with folks who try to own nothing and push work to other teams/individuals, and when things go wrong, they are the ones passing the blame as well. To no surprise, no one wants to work with them more than once.

Bugs will only get worked out if the code actually gets used. You cannot wait until something is perfect before adopting it. You will wait forever. Remember that Agile is micro failure on a macro level. Adopt quickly, deploy quickly, fail quickly, adjust quickly.

There are always opinions on how to ship a product, but I love building the simplest form of the product and deploying it and then iterating on it quickly. Projects that are developed for months and then leave deployment until the end as an afterthought usually run into a wide array of integration issues. At that point, that is unplanned work with no clear estimate of how long it will take to fix.

Disney World, the Magic Band and Apple Watch

/
Disney-Magic-Band.jpg

A few weeks back I went to Disney World. It also happened to be about a week after I received my Apple Watch. The two may seem unrelated but Disney World is foreshadowing what Apple Watch will be in a few years.

When you buy a ticket at Disney World you have the option to also purchase a Magic Band. The Magic Band is an NFC wrist band that serves as your identity while you're at the Disney World Resort (and Disneyland for that matter). You use the Magic Band to enter the park, sign up for Fast Passes, Pay for Meals/Souvenirs and even to create magic.

An example of such magic is at the "Be Our Guest" restaurant. When you enter the restaurant you wave your Magic Band at a touch screen kiosk and order your meal. The payment is automatically charged to your account, and the kiosk directs you to find a table. You sit at the table and a few minutes later your meal arrives. It really does create a moment of delight wondering how they knew where to take your food.

How? The table you sit at is a little thicker than a normal table in order to house an NFC reader. When you sit down it notifies the staff where to bring the food. When you are done eating your table notifies staff to clear the table. 

Disney is on an entire new level of user experience design. They used technology to make a highly efficient restaurant but also make a delightful frictionless user experience. What does this have to do with Apple Watch?

Apple Watch has only been out a month, so we are in the very beginning of the ecosystem. In a couple years Apple Watch will be as central to your everyday life as the Magic Band is when you are at Disney World. Apple Watch is emphatically you, bringing an increased level of security. Essentially while wearing the watch you are a walking 2 factor authenticated user, that opens up an entire new world of possibilities. 

In the not to distant future you will checkout at Whole Foods, pay with your watch and walk to your car. You will wave your hand at the trunk and it will open. You wont need a car key anymore. Better yet, your car knows whether you or your spouse is driving and adjusts the seats and climate for you. When you get home your garage door just opens. When you're all out of the car it simply locks. The best part of this story is that you didn't have to interact with a single UI.

All of this is possible with Android Wear of course, and Android watches came out first. However, only Apple can truly unlock this future. They started laying the plumbing for this years ago. Passbook came in 2012, TouchID/CarPlay came in 2013, HomeKit/HealthKit and Apple Pay came in 2014 and of course Apple Watch in 2015. This year, rumors are swirling that Apple TV/HomeKit will be central to WWDC. Once Apple ties your phone and watch to your home most of the above is possible within a year. The car is a few years away but Apple has been laying the infrastructure for it for years. 

After this story becomes a true story, I would expect brick and mortar retail to have a small renaissance. If we can remove friction from the physical world the web as we know it will feel antiquated.

Stand for Apple Watch

/

I've now had my Apple Watch for a couple of weeks.  One thing that is a bit annoying is the charger. I charge 2 phones on my nightstand and I'm constantly knocking the charger off my watch.  Apple Watch needs a stand, so I looked at several and found this Spigen stand to be the best stand for Apple Watch.  I'm a big fan of Spigen's products and this a pretty reasonable stand at $20.

$19.99
Spigen
Buy on Amazon

When to use AWS

/

I just moved all of my personal hosting off of AWS recently. The primary reason was cost. AWS is expensive especially when your requirements are static.  

For example, your application needs 5 servers with an elastic load balancer plus a multi-zone RDS MySQL instance, the minimum you'll pay per month is north of $250 for fairly low powered VM's.  Even if you use reserved instances you're average monthly cost will still be around $200.

By switching to a more standard VM hosting company, you can easily get your average monthly cost to around $100 (or even less if you don't need a lot of CPU's).

Personally, I switched to Linode.  I found their offerings to suit my needs and I'm now saving 66% per month.  What am I losing? Practically speaking, nothing. Hypothetically I'm losing a lot of flexibility that AWS offers.  AWS has robust support for API management of hardware, auto-scaling, automated RDS backups and a lot more obviously.  But my requirements are pretty static, so I am comfortable with the trade-off.  

Amazon is doing great things in this space and releasing some great technologies.  In doing so they are creating feature/platform lock-in with early stage technology companies.   Amazon is doing with AWS what Apple is doing with iOS/Mac.  By making the switching cost so high Amazon is ensuring the long term viability of their business.

I love AWS and I will continue to use it for new projects where the requirements are a lot more fluid.  Once the project reaches a point where the requirements are set, I'll then deploy it to another hosting provider.  

Official BMW Remote App Updated

/

BMW finally updated their remote app. I was excited to see the update come out, however BMW yet again disappoints in the app space. 

There were a host of changes in this update. Beyond a fresh coat of paint and new icon there are also some other enhancements. When logging in for the first time, they have removed a redundant password prompt.  They have also changed the home tab to the vehicle action screen (lock, unlock, ventilation, etc). The vehicle locator has been moved to a secondary tab. 

While some progress was made, BMW really missed the point with this update. They did remove some steps from the process of locking your car but the core underlying issue remains. When you send a command to your car, you have to keep the app open and wait to verify that your car has been locked. This can take up to 5 minutes if it works.  If there is a limitation that causes such a delayed response, don't make the user feel that pain. Handle the command on the server side and send me a push when it succeeds or fails. 

The app is still missing the killer feature. The app needs to be registered as a Transit Provider with Apple Maps so we can send directions to our cars.  This would be a seamless integration versus opening the remote app, going to the location tab, searching a different database and sending directions to the car. When I reverse engineered the old Remote App and built my own, I added this feature in 2 hours and I use it all the time. 

In the luxury car market, a great companion app is almost a requirement now. Tesla's app is phenomenal and other auto makers are not far behind. But BMW lags behind. This update feels like a low budget update that product marketing shoved upon a third party developer. 

I never released the BMW Remote App I built because it was a project that was intended for me. When I explored making it for mass consumption the main issue was testing it on different types of cars with different features.

I'll probably reverse engineer this update to see if there are any new cool features that can be made. I'd love an iOS 8 extension or widget to get quick access to my car.  

How do I get the best iPhone Battery Life

/

I have this pet peeve of people giving bad advice about technology.  The number one is how to optimize battery life, specifically the iPhone.

I saw one article that even recommended turning off wifi to improve battery life.  While conceptually true, in real world practice, absolutely false. 

With the iPhone 6 and 6 plus, battery life has never been better.  However there are a few things I do to optimize my battery life.

Turn down the screen brightness

This one seems obvious, but a screen emitting brightness (energy) uses more energy.  I keep mine at about 20% brightness with auto brightness control on.  This way it gives me what I need if I'm in direct sun light but then backs down when I'm not.

Use WiFi whenever possible

At home and work, stay connected to WiFi.  Not only will your connection speed likely be faster on WiFi, you won't be using the Cellular Radio unless you take a phone call (which will soon change hopefully).  The cellular radio drains the battery, especially if you are in a poor signal area.

Be smart with location access

Only enable location services for apps that actually need it.  In practice, I keep location services on for most apps, as I don't use most apps frequently.  However, if an app keeps monitoring location and I feel it doesn't need it, I just turn off location access for that app.

What doesn't impact Battery Life

  1. Push Notifications - Unless you're getting dozens a minute, there wont be much impact. All that is being sent to your phone is less than 1kb.  All of this is moot if you're on WiFi.
     
  2. Bluetooth - If you're not connected to anything, the amount of energy your phone is using for Bluetooth is pretty small.  Even with streaming music, newer iterations of Bluetooth chipsets have become fairly good at minimizing energy usage.  Conceptually yes, it does impact battery life, but not in a meaningful way if you charge your phone every day.

In the end, just think in terms of energy in vs energy out.  Your screen emits energy, your phone's cellular radio emits energy, and other radios emit energy (GPS, wifi, bluetooth).  Basically, you just need to optimize which energy sources are used.  The screen, cellular radio (3G in particular), GPS are the biggest offenders so focus your efforts there. After that, quit worrying about it.

New Adventure

/

On Monday I start a new job at Fanatics. It's a great company with awesome people in an amazing industry.  

It was bittersweet to leave eBay, especially working on (in my opinion) the best team in the company. I'm still extremely excited about what they are working on. I'll share what we were working on once it has launched.

I started at eBay thinking I'd only work there for a couple of years and move on to something else.  6+ years later, and I couldn't be happier with my experience at eBay.  I got to work on some huge backend systems, iOS and Android apps with millions of users, and countless proof of concepts.  More importantly, I met some extremely talented people and made a lot of friends.

PHP Library for Telemetry App

/

This weekend I had a project that required me to create a live dashboard. I found Telemetry (http://telemetryapp.com) and it looked perfect for what I needed. You simply submit new data for the dashboard via their API. They have clients for Mac, Windows, Mobile and Web to view the dashboard. Unfortunately they only had a Ruby Gem to interact with their API. I had a requirement that it needed to be in PHP, so I was on my own.

Over the course of the weekend I built a fully-functional library for Telemetry in PHP and it supports all of their different data flows. I put it up on GitHub so others could use it.

Telemetry GitHub Repository