How To: Sideload & Install Open Source iOS Apps on Your iPhone Using MacBuildServer—Without Jailbreaking

Sideload & Install Open Source iOS Apps on Your iPhone Using MacBuildServer—Without Jailbreaking

How to Sideload & Install Open Source iOS Apps on Your iPhone Using MacBuildServer—Without Jailbreaking

Apple is widely known for keeping a tight grip on iOS, disallowing open-source and third-party downloads. While there are many reasons for this, the three most frequently referenced are quality control, malware prevention, and of course—money.

The number one reason why Apple rejects apps from the App Store is because they crash. Second is security, because they don't want users downloading viruses or trojans that could harm devices or steal data. Of course, Apple always keeps 30% of app revenues for themselves, so it's beneficial to them to make sure only the highest quality apps make the cut.

The review and signing process helps to deter bad eggs, and gives them the option to universally ban any app and/or developer that slips through the cracks.

But There's an Exception

Since they're notoriously careful with their approval process, monitoring any circumvention and nipping it quickly in the bud, I found it surprising when I was able to easily download a third-party Game Boy Advance emulator on my iPhone 5 directly from Safari without any issues—and without jailbreaking.

How Does Something Like This Happen?

The person hosting the jailbreak-free GBA emulator app started by finding the emulator's open-source code on GitHub (which was purportedly based on gpSphone by ZodTTD, an avid software porting hacker whose work includes several emulators).

At this point, anyone with a Mac and some basic coding skills could fire up Apple's freely available Xcode, clone the Git-repo, compile the app, and use Xcode to install it on an iPhone. But, to build and sign an .ipa file that can install on any non-jailbroken phone isn't so easy.

Building Open Source iOS Apps with MacBuildServer

MacBuildServer, to the rescue. Our emulator hosting friend simply plugged the read-only Git URI into the incredibly easy process available on MacBuildServer, which automatically clones the Git-repo (i.e. snags a copy of the source code), builds the app, then signs it. It's just like the process you might go through with Xcode, but without any of the hassle.

Image via wonderhowto.com

We reached out to Sergey Dmitriev (@blackie6 on Twitter), one of MacBuildServer's co-founders, to find out more about how it works, and more specifically, how apps built with their system can be sideloaded without having to go through the iOS App Store.

Image via twimg.com

When asked if I would need to bring my own certificate, Sergey was very clear: "Every user of MacBuildServer should have their own certificate and sign their apps with it."

However, in the case of MacBuildServer's demo page (which seems to be under heavy load... be prepared to spend about an hour on it), I was given the option to "Skip this step" without uploading my certificate. When I asked about this, Sergey replied:

"We do sign the apps compiled with MacBuildServer with our own enterprise certificate just to show how easy the whole process works, this implies that you only use it to test the apps. We do not have any limits (at least we never reached one).

"So technically you don't have to have your own certificate, but you better have one. :)"

For the record, I do.

The end result is that MacBuildServer's demo gives you a three-click process to build any open-source iOS app you can find on GitHub, and sign it with an enterprise certificate that allows jailbreak-free sideloading for your own testing purposes.

Seeing as you're compiling from the source code, you are technically testing... right?

But Wait... I Thought iOS Didn't Allow App Sideloading?

Stock iOS does not typically allow the side-loading of unsigned apps—the only way to currently do that is with a jailbreak. The signing process MacBuildServer uses to cleverly skirt this limitation is to have you use your own certificate, or to simply use their certificate from the iOS developer enterprise program to sign the compiled app (again, for testing purposes).

The iOS Developer Enterprise Program

The iOS Developer Enterprise Program was designed to allow companies to develop in-house apps for use within their organization, without publishing them on the App Store.

An example of a business that would be part of this program would be an event coordinating business that uses these in-house iOS apps to check people in and perform other tasks.

Image via tabtimes.com

But getting into the enterprise program isn't quite as easy as the standard iOS developer program. A developer must have a legit business in order to get in—a Dun & Bradstreet (D-U-N-S) Number is required for enrollment, which appears to be a credit-checking system that verifies the trustworthiness of the business.

Once in the iOS Developer Enterprise Program, it "allows you to distribute your apps to employees or members of your organization through Ad Hoc distribution."

Gaining Access to In-House Apps

So, how exactly do we get access to an enterprise signed application? To understand that, you'll have to look at the process of how in-house apps are deployed to employees/members:

  1. First step is to register for the iOS Developer Enterprise Program.
  2. Next, you'll need to prepare your app for distribution.
  3. Then you have to create an enterprise distribution provisioning profile, which authorizes any devices you want to use the app.
  4. Finally, build the app with the provisioning profile and deploy it to all of your users.

The key part of the this list is the enterprise distribution provisioning profile, which allows you to send out your app to be installed on an unlimited number of iOS devices (as opposed to the typical 100-device limit set by the regular iOS Developer program allows).

The Grey Area - Distribution

Since the distribution of in-house apps is restricted to your employees/organization-members, it seems that by installing a signed sideloadable app, you would technically have to consider yourself a part of the organization, so as to abide by the agreement.

When it comes to distributing an open-source app like the GBA emulator using an Enterprise certificate, we get into a grey area with the enterprise agreement.

It's hard to verify that people downloading the app are part of the same company or organization that signed it. It would seem that anyone an enterprise distributes one of their signed apps to would be implicitly a member of the organization they want the app distributed to. Plus, if you're helping to test an open-source project, that would seem to satisfy the requirement too.

Then again, if you want to be extra safe and you know a thing or two about coding, you could help fix one of the open bugs and submit a pull request, clearly documenting your involvement with the "organization" developing the app. So, I'll just assume that's what you're doing.

Installing Enterprise-Signed Apps

Enterprise-signed apps can simply be downloaded from any website onto any iOS device, or sideloaded using iTunes. Whenever a user opens an enterprise-signed application for the first time, the provisioning certificate is validated by contacting Apple's server, which then allows the app to successfully run.

You can check out the certificate that appears on your device after a download, if you go to Settings -> General -> Profile (like in the pictures below, for iOS 6 and iOS 7).

Image via wonderhowto.com

The validation response from the Apple server is then cached on the device for between three and seven days, after which the certificate is rechecked for validity anytime your phone is restarted or the cache response has expired.

So far, my emulator is working fine. I'll check back in a few days and see if Apple shuts it down and closes the provision. Hopefully not, because the MacBuildServer is a great boon to the iOS open source community, even offering a GitHub install button for iOS projects.

And besides... I'm in the process of finishing my "backup copy" of Pokemon Red.

Photo via TabTimes

1 Comment

Share Your Thoughts

  • Hot
  • Latest