You probably know how time-consuming it is to ensure your app follows the latest app review guidelines. App store rules can be complicated and hard to remember because they are constantly changing, but all developers need to follow them to avoid rejection. 

 

That’s why today, we’re excited to introduce fastlane precheck to save you the time and hassle of auditing your own app! fastlane precheck reviews your app’s metadata (in seconds) to catch the most common metadata rejection errors, such as mentioning other platforms or having broken URLs.

 

On a personal note, I’m super thrilled to launch fastlane precheck because it’s the first new iOS tool we built since joining Google.

 

Read the full announcement on the Fabric blog. 

Open on GitHub

Initial Version: WWDC 2016

The very first version was basically a set of location sharing groups on line.here (app is now discontinued). The app quickly ran into the limitations of the line.here platform.

WWDC week in San Jose is exciting and overwhelming at the same time: so many iOS and Mac developers all in one city. You finally have the chance to meet all the people in person you interact with online usually.

By making a real-time map of all developers you’ll be able to spontaneously meet nearby developers or join other groups.

Custom App: WWDC 2017

The following year I’ve built a custom app, and used it to learn Firebase and React Native.

The app is fully open source, and you can find the source code on GitHub. Due to the name, and me not wanting to deal with the App Store Review guidelines, the app was distributed through TestFlight.

WWDC 2018: ConfFriends

In 2018, I’ve decided to hand over the app to @ay8s, who re-wrote the app using native code, and renamed it to ConfFriends (to prevent any issues with Apple). With that, I’ve stopped working on wwdc.family.

All those hours you spend on getting code signing to work properly on your machine, on your CI and on your co-workers Mac… your app and the App Store would be just a safe and secure without it.

Is code signing really a problem for developers?

Yes! On the fastlane repo alone, over 1,700 GitHub Issues are related to code signing. That is over 30% of all incoming requests. On Stackoverflow you can find over 3,000 questions around iOS code signing, even though it’s not related to actual code.

Why do we have to codesign iOS apps?

Code signing is one of the most crucial security components of the iOS ecosystem:

• Code signing allows Apple to control what software can be installed on iOS devices. 
• Code signing ensures your app doesn’t get modified by a third party on the way from your Mac to the end-users iPhone.
• You sign your app with your signature, it ensures that the app is from you.

What’s the problem with the current process?

Once someone has access to your Apple credentials, they can easily revoke all your certificate, create new ones, and update the provisioning profile to use theirs. 

• When you submit your iOS app for review, the app gets resigned by Apple after being approved, so your code signature isn’t actually used when the end-user downloads your app.

• When you create a new Certificate Signing Request you can select Saved to disk. This means, if someone has access to your Apple Developer Account, they can create as many new, valid certificates as they want, without having access to your email account.

For many iOS developers, the account credentials never leave their computer (e.g. if they use Xcode and fastlane), but there is also a handful of third party web services that ask for your Apple ID credentials, which are then stored on their servers. If the service isn’t open source, there is no way for you to know how the credentials are stored and secured.

How to fix iOS code signing? (see what I did there?)

Don’t require developers to codesign, or make it completely automatic

Don’t require code signing locally on the developer’s machine at all. Tools like the iTunes Transporter already verify the checksums and validity of the uploaded binary. Just by doing this one thing, you never have to deal with code signing again. 

And assuming your Developer account doesn’t have 2-factor auth enabled, there would be no difference in the security across the whole process.

The alternative would be to do all the code signing completely automatic in the background via Xcode. That’s already the case (previously known as Fix Issue button), and it works great for some use-cases, however once your team reaches a certain scale, you’ll quickly run into its limits (see codesigning.guide).

Enforce 2-factor

Enforce 2-step verification for all Apple Developer accounts, offer a way for teams to easily add multiple phone numbers or email addresses. Access to production apps is important enough to enforce 2-step verification for all accounts.

Require 2 factor auth before resigning the app

Once your app is approved, the owner of the app should be asked to confirm that this version should be shipped. This can be done either via email or SMS verification, but not via the iTunes Connect Web UI directly, as otherwise people with access to the portal could confirm your app release. This could even be its own iTunes Connect role.

Entitlements

Right now Entitlements are set up on your local machine. This could either be moved onto the server side on iTunes Connect, or work automatically under the hood on your local machine

Local code signing is still required for Development builds

You’ll always need to sign your app to install it on your actual device, however this became a lot easier over the last two years, as more and more people can use their personal Apple ID to install their app on their real device. This is actually quite critical, as local code signing was abused by multiple app providers to enable people to install apps that are not approved by Apple (e.g. Flux for iOS)

Ad Hoc builds still require code signing

The above mentioned techniques won’t work for Ad Hoc builds, code signing should still be required as before.

In 2010 we visited the Google campus on our family trip to California. Ever since then I knew I wanted to work here at one point in my life. Today, 7 years later, I had my first day at Google in Mountain View, joining via the acquisition of Fabric. I’m so happy that I reached this goal, and I can’t wait for what I’ll learn over the next few months and years.