linux on ios,Developing an iOS app on Linux in 2017

I've just published an iOS app on the app store, I developed it (mostly) using

Linux (Ubuntu). Here I have documented some of the challenges and discoveries

for anyone considering doing the same.

Before anyone gets too exicted, this is a

Cordova app. That means it basically a web app

(HTML, CSS, Javascript) served in a web view. There's no Swift or Objective-C

here (at least, not written by me). Furthermore, my total solution uses two

hosted Mac OS offerings. The day to day development still sticks to Linux, but

I didn't find a solution that doesn't touch Mac.

This post won't go in to much detail about the limitations of a cordova app over

a "native" app, as these are already documented elsewhere. I will

say that you can produce a decent looking, responsive, completely offline

application that Apple will accept on their app store using this mechanism.

Linux and iOS Development

Apple are not exactly known for making development for their platforms easy

on operating systems that aren't Mac OS. If you look in to this you will find

people on the internet advising that even developing a basic Cordova app would

be made a lot easier by buying a mac.

But I'm a Linux user, so I'm not necessarily that interested in making my life

easy.

When I started out my main concerns were:

Testing my app locally in an emulator.

Building a release to to test on an iPhone.

Running my app on an iPhone.

Remotely debugging my app on an iPhone.

Building an app store ready release.

Uploading my release to the app store.

It turned out these were all things to be worried about (some solveable, some

not), I'd missed one:

Producing screenshots for the app store.

Development Environment

Before we address each of these points I'll give you a quick overview of my

setup. I went for the classic gulp/bower/npm/etc. combo. I used the AngularJS

framework.

I used a generator to get

started. I ultimately regret this, it got me going quickly but left huge gaps in

my knowledge. Next time I would use such a project as a reference, but hand

pick the pieces I wanted.

This generator gave me some .html and .js I could edit, some commands I could

run to serve them to my web browser from a local web server.

With this and Chrome Device Mode

I was able to develop a web page and look at what it might look like on an iPhone.

Whilst that's OK, Chrome is not the web view that Cordova runs on the iPhone, so

we don't really have any guarantees that the app will look as we see it on our

computer. That brings us to the first concern.

Testing my app locally in an emulator

It's quite simple - if you don't run Mac OS you can't run an iPhone emulator.

There are browser plugins (and the previously mentioend device mode) that will

make a browser sort of look like a phone, but that's your lot.

Personally I found that for 95% of cases Chrome was similar enough. The other 5%

we'll get to later.

(See "Producing screenshots" if you really want to run an emulator).

Building a release to to test on an iPhone

Again, this I couldn't achieve purely on Linux. This brings us to my first cheat.

Adobe Phonegap is a commercial service based upon

Cordova. If you create a (free) account with them they will build iPhone

binaries for you (for free).

There's one more hoop before that will work - certificiates. The iPhone

won't accept a binary which isn't signed by a certificate from Apple. And the

only way to get your hands on one of these is to give money to Apple.

Once you sign up and pay for an Apple Developer account you will get some

development certificates. You plug these in to phonegap, along with your

project's git repo, and a .ipa file is produced.

Running my app on an iPhone

Here comes our first pleasant surprise - I can take my phonegap built .ipa and

install it on to my iPhone straight from Linux using

ideviceinstaller. It's

this simple:

ideviceinstaller -i app.ipa

WARNING: could not locate iTunesMetadata.plist in archive!

WARNING: could not locate Payload/app.app/SC_Info/app.sinf in archive!

Copying 'app.ipa' to device... DONE.

Installing 'net.app.example'

Install: CreatingStagingDirectory (5%)

Install: ExtractingPackage (15%)

Install: InspectingPackage (20%)

Install: TakingInstallLock (20%)

Install: PreflightingApplication (30%)

Install: InstallingEmbeddedProfile (30%)

Install: VerifyingApplication (40%)

Install: CreatingContainer (50%)

Install: InstallingApplication (60%)

Install: PostflightingApplication (70%)

Install: SandboxingApplication (80%)

Install: GeneratingApplicationMap (90%)

And that's it - I get my app running on my phone exactly as it will be when I

sell it. It pops up on the home screen and I can launch, easy.

Remotely debugging my app on an iPhone

As anyone who's written code for a browser will know - browser quirks can be the

most infuriating issues to code for and around. This is the 5% of problems I

mentioend previously.

Whether it's CSS or Javascript - being able to open the debug console and tweak

things is incredinly useful. As you may have already figured out, the cycle of -

commit to git, push to git, build binary on third party service (phonegap),

download binary, install binary to phone, launch binary - is not exactly a quick

feeback loop.

This brings us to our second pleasant discovery. We can use the

ios_webkit_debug_proxy in

conjunction with our running app. This allows us to use Chrome devtools on our

computer, attached to the Safari webview running in our app on the phone. This

makes debugging all manor of browser specific problems a lot easier.

$ ios_webkit_debug_proxy -f chrome-devtools://devtools/bundled/inspector.html

Listing devices on :9221

Connected :9222 to Andrew's iPhone (c8fed00eb2e87f1cee8e90ebbe870c190ac3848c)

It's that easy - then through Chrome I can twiddle CSS and run Javascript in my

app.

Building an app store ready release

This is the same as how we build our .ipa for testing, the only difference is we

have to use some different certificates from Apple. The process is otherwise

identical - and phonegap will pop out a production ready .ipa.

Uploading my release to the app store

This was a bit of a shock. Naturally on a mac this process integrates in to

XCode and those lucky developers can upload to the app store (iTunes Connect) at

the push of a button.

I had assumed there would be some web interface (as there is to configure all

other pieces of the app) to allow for submission of our binary. This is not the

case.

Your two options are:

XCode

Application Loader

Both of these are native Mac OS tools. This brings us to our second cheat.

Unfortunately phonegap aren't kind enough to offer this service for us, but

there's another option: MacinCloud. For a fee ($1

an hour) you can access a full blown Mac OS instance with Application Loader

available (accessible via rdesktop).

Using this service, it's possible to upload the .ipa to the app store for public

release.

(In searching for solutions to this I also found various

random-people-on-the-internet who in exchange for some cash and all your Apple

login details would submit your app for you from their mac. I did not go down

this fairly sketchy route).

Producing screenshots for the app store

We're not quite finished yet! Chances are you want to upload some screenshots

of your application. iTunes Connect has a thing called Media Manager which will

helpfully take screenshots of the highest iPhone resoltuion and scale them down

for you. At time of writing this is 2208x1242 pixels. That is unfortunately more

pixels than I have on my laptop.

There's no verification of the images you upload (from what I can see), so you

could fake these in any way you like, but if you want to produce a bunch of

screenshots of your actual app you may end up doing what I did - uploading your

code to Macincloud, running it in Xcode and using the iPhone 7 emulator +

screenshot functionality.

Conclusion

Whilst there were a few hoops to jump through in this process, the whole ordeal

was not that painful. Throughout the project I was prepared to just go and get a

mac but I was keen to avoid this if I could.

The main times I found myself truly swearing at my computer were when I was

trying to set up plugins - for which

(when I got things wrong) the feedback loop was infuriatingly slow.

All in all I think it was fine to do it this way and I'm glad that to maintain

my iOS project I can use my regular development environment. Admittedly, a great

deal of the ease comes from the fact that this is a web app - which should be

easy to develop on any platform.