Micro Focus is now part of OpenText. Learn more >

You are here

You are here

End of the iOS hot patch : 4 ways your mobile dev team can adapt

Grant Gross Reporter, Freelance
iPhone updating

Apple’s App Store sent some developers scrambling earlier this year when the company cracked down on the ability to issue so-called hot patches.

Citing the potential for man-in-the-middle attacks, Apple told developers in March that it would no longer allow them to change their apps’ “behavior or functionality” outside the company’s app review process.

Apple’s message to devs: Stop using services like Rollout.io for quick bug fixes.

The decision originally raised some questions and confusion, but about three months after Apple sent the warnings to developers, some have found ways to work around the rules, and others have focused on working with Apple.

Other developers have downplayed the Apple move, saying the company has streamlined its app review process in recent years. Trey Stout, CTO of ScribbleChat app maker Handwriting.io, said Apple’s decision to crack down on hot patching comes at a time when smartphone users are downloading fewer apps, with many getting app-like functionality through platforms such as Facebook instead. 

It was clear developers were trying to get around Apple’s app approval process using the hot-patch methods the company rejected, Stout added. Rollout.io didn’t respond to a request for comments on the Apple decision, but the company in March said it was disappointed with the change.

“[Rollout.io’s mission is] helping developers create and deploy mobile apps quickly and safely,” CEO Erez Rusovsky said in a blog post. “This benefits developers and end-users alike and has prevented—by a conservative estimate—millions of crashes.”

Some developers had a different view. Arthur Ariel Sabintsev, a lead iOS developer at The Washington Post, said Apple’s decision to crack down on hot patches made sense as a way to ensure app quality. Apple was responding to a service that gave developers the ability to inject code into an existing app without going through the App Store review process, he said. “Unfortunately for them, Apple has rules against that in place.”

While most teams are not using the hot-patch process, many are. Here are four strategies to deal with the App Store changes.

1. Less patience required: One-day turnaround

Between 2015 and 2016, Apple cut the app review time from over a week to about a day. The old time frame could be “devastating for a brand dealing with a bug in their app,” said Alex Fishman, CEO and founder of Bugsee, a bug and crash reporter for mobile app developers. “But Apple has greatly improved this process.”

2. More QA: Kill bugs before release

Apple’s move to end hot patches should be a signal for developers to put more effort into killing bugs before release, Fishman said. Apple’s decision may have a good side effect, he said. “If you know you have a bug, and you know it will take another day to update it, chances are you will put more effort into QAing it.” 

3. Ask Apple for a quick fix

Besides streamlining its app approval process, Apple is responding to developer requests for faster approval when fixes are critical, Fishman said. “If you need faster than a one-day turnaround, you can always reach out to Apple for an urgent update,” he said. “Experience shows Apple is there to help developers to speed up urgent fixes.”

Apple has a formal expedited review process, noted William Volk, a mobile game developer and chief futurist of Forward Reality, a virtual reality publisher. Apple warns that expedited reviews are available on a limited basis, however, he added.

4. Server-based app changes: Use hidden features

App developers also have other options, including the ability to later turn on hidden features, Sabintsev said. "What developers have always done, and will continue to do, as it is still considered kosher, is to bake a bunch of hidden features into the app and control how and when those features are turned on using a remote configuration file store on a server owned by the developer.

“The reason this is fine is because Apple reviews and analyzes the entire executable when they review the app,” Sabintsev said.

Volk also suggested developers can move much of their apps’ functionality to web-based services as a way to make them more patchable. “For many apps, this can work,” he said. “The app becomes a client that accesses web-based functionality on servers. The downside is that connection is required and performance can suffer.”

Many game apps rely on table-driven decision-making functionality that also comes from their servers, Volk said. Other apps may be able to use similar programming to serve dynamic content.

“If the app has some sort of decision making—say it’s evaluating user inputs to some conclusion—that could be driven by a table of values that can be updated, by the app, when it can connect with the server and determines that an update of the table is needed,” he said.

Many apps depend on the ability to make dynamic changes, using JavaScript code and other methods, noted ScribbleChat’s Stout. Without the ability to make server-based changes, an app such as Yelp would have to go through Apple’s formal app review process every time a user rated a restaurant, he said.

Another example: Graphics-based chat app ScribbleChat can provide users new visual effects using JavaScript without going through the formal app review process, he said. But these types of changes don’t change the underlying functionality of an app, allowing Apple to protect users from major unwanted changes, he noted.

“Apple can’t ever get so Draconian about it” that app developers can’t make any code changes on the fly, he said. “Apple would have a really hard time mandating that the only dynamic stuff that can come into an app is data, because it’s essentially impossible to prove.”


Keep learning

Read more articles about: App Dev & TestingApp Dev