“Walking opens us up to the menace of a world outside the built environments that we control. Driving, despite the high risk of crashes, injury, and death, masks itself as freedom: we’re not watching our backs. And once we’ve become unaccustomed to the movement of the air, the rustle of the trees, the sight of other people, they can startle. People who move differently and think differently from us become, from the safety of our fortress-homes and echo-chamber media and car-conduits that feed it all, threats to our way of life. And so we design towns and suburbs, neighbourhoods and cities, unfriendly to the walker, to those who break out of the paradigms we’ve deemed safe.”
By including content blockers in iOS, Apple now allows developers to build ad blocking apps for mobile Safari. But more importantly, Apple has started a conversation about the ethics of ad blocking on the web. After only a few days Apple has (inadvertently?) pushed the topic into the limelight. With the advent of content blocking apps, people show they are willing to pay a some amount of money to block ads.
But when users pay, to whom should the revenue go? Solely to the developer of the ad blocker? Or shared amongst the developer and web content producers? Sharing revenues is easier said than done, but for online publishers who make a living off advertising, cutting ad revenue is a serious detriment to their livelihood.
Ad blocking offers not only an aesthetic improvement, but also a considerable performance boost in both web page load time and data usage. For those on mobile web browsers (such as Apple’s safari), cutting out web tracking and advertisements can extend the life of a constrained mobile data cap.
Regardless of their reasons, people want a fast and focused web experience without any distractions. Maybe its time for a different advertising model, or a brand new way to monetize the web. Let’s see where the conversation progresses.
I recently submitted my first iOS app to the App Store and spent quite a bit of time searching ways to navigate some of the less intuitive parts of Apple’s submission process. Tons of guides walk through step by step, this is meant to help fill in the gaps.
For those looking for a overview, start with this great tutorial and come back to this post for more info.
There are a lot of great resources to learn about Objective-C, Xcode, and app design. Here are a few to get you started:
- AppleProgramming on YouTube
- Objective-C book
- Apple Documentation (tough to sift through for beginners but useful nonetheless)
- Stack Overflow (but stay away from blindly copy and pasting, writing the code helps you learn!)
While learning, if you see a piece of code I think I need to incorporate, copy it into an open space your program, but re-type it in the correct location. This saves the hassle of alt-tabbing between windows or looking back and forth, but gives you the opportunity to gain the muscle memory of typing the code. Just make sure you actually type the code!
Sign up for an Apple developer account. The account costs $100 a year but is needed for testing on actual devices and then submitting to the app store.
iTunes Connect vs Apple Developer
Use the same email for both
One email can be connected to multiple Apple Developer accounts, but iTunes Connect is limited to one email per account. However, using two different email addresses can cause issues when submitting app from Xcode to Connect. Xcode checks if the Developer and Connect account email addresses match, rejecting submission if they are different. So save yourself the trouble now, and use the same email for both Apple Developer and iTunes Connect.
If you have a Gmail address, you can add a “+” to the end of your address to create a “new” email that will send to your original account. For example, say your email is firstname.lastname@example.org. You can append “+dev” to create email@example.com. This address will still show up in your firstname.lastname@example.org inbox, but Apple (and other sites) will see the modified version as a completely different email address.
Switching to a Team
Follow this link to the Apple developer team support page and scroll to “If I am enrolled as an individual, can I change to a company membership?” (Yes!). From there, send a message to Apple explaining you wish to transfer your account.
There is about a seven day process of switching a person account to a company account. If you are on a deadline, make sure you start this soon. Changing will also require the DUNS number to identify your company.
Once the team developer account is set up, you need to add members to both the Connect and Developer accounts for the company.
Uploading to iTunes Connect
Hooray! So all the accounts are set up and you are ready to upload version 1.0 of your app! You log onto Connect, hit the “+” and are greeted with this screen:
Unless you app name is in Esperanto, there is a good chance someone already tried to register the app under the same name. Take a look a the App Store, many apps have a small tagline at the end of the actual name. If your app name is already taken, you can try this naming convention for the App Store page:
Don’t worry, the name shown under the app icon will stay the same, this name is for the store purposes only.
Should match the version number of your app in Xcode.
Main spoken language used within the app. Used in tandem with the localization settings of your app (or Swahili).
The SKU number can be just about anything. Using the date format YYYYMMDD is common.
The Bundle ID can be found in Xcode by navigating to Project > General, but to enter the ID here, you must register your app within the Apple Developer site. Here are some links to help with the process:
- Distributing iOS app with iTunes Connect (Part 2 – App ID)
- Configuring Your Xcode Project for Distribution (About Bundle IDs)
Generating buzz is of utmost importance when releasing a new app. There are many sites designed with the sole purpose of boosting awareness for upcoming apps. For those with grand business ambitions, BetaList focuses on discovering the next big startup. Apps featured on BetaList are often multifaceted with online and mobile components. For fun and entertaining apps, PreApps is the place to go. Mr Jump is a great success story from PreApps, generating over 5 million downloads in the first 4 days, but the site works just as well for any app looking to gain some traction.
App Store Prep
Ensure your app adheres to all of the App Store Review Guidelines. The list is quite long, but read it carefully. Violating even one guideline will cause your current app build to be rejected. The most common reasons for rejection are summarized here.
Store Page Todos
To take a screen shots of your app, hit Command-S while running the device simulator in Xcode. With screenshots in hand, check out sites like Davinci Apps and LanchKit.io to easily add a caption and display the app screenshots on an iOS device.
1. US Export Compliance (iTunes Connect Question “Does your product contain encryption?”)
To ensure your app is compliant not only with Apple, but also the US government, it is crucial to understand the encryption technologies used in your app. Here is a link from the Bureau of Industry and Security regarding encryption. There seems to be a bit of confusion surrounding the correct process:
- Does my application contain encryption (StackOverflow)
- What constitutes encryption for the purpose of export compliance (StackOverflow)
- Using SSL in an iPhone app export compliance (StackOverflow)
However, a commonality is if you think your app includes encryption, whether you wrote it or not (including https and SSL), you should select “Yes” for the export compliance question and provide your ERN (Encryption Registration Number) when you submit your app.
2. Advertising Identifier (IDFA)
Some 3rd party SDKs (such as Facebook) use the IDFA, so check with any 3rd party code before you answer this question. Otherwise your app may be using the IDFA without you knowing, resulting in Apple rejecting your app submission. As an example, if you are using the Facebook SDK to track app installations, select the second checkbox attributing use of the IDFA for app installs.
App Store Submission
Review takes about a week (7-8 full days). You can check the average app store review times, but once your app is taken from the “Waiting for Review” queue, Apple reviews the app extremely quickly.
In special circumstances, if you need your app to be reviewed faster, you can ask for expedited review. Apple is not guaranteed to grant expedited review, and they only make a one-time exception.
Carefully read over Apple’s reason for rejecting your app. This can be an infuriating process, but try to stay calm. Make sure you adhere to the app store guidelines (you read through this earlier, right?), and fix the issues outlined.
Ready For Sale!
Green light! Time to release! Not quite yet.
Make sure you have some buzz around your app. This part is tough, but the right marketing strategy can make or break the success of your release! Hopefully PreApps and BetaList worked to generate some interest, but now is the time to recruit as many people as possible to help spur initial launch popularity. Make a Facebook page, Twitter account, try to contact some websites catering to your target market, and let your friends and family know! Product Hunt is a great site, but good luck grabbing an invite and being featured. And hey, don’t forget to let me know! Comment with any apps you released after reading this post!
If you made it this far and enjoyed the post, please consider checking out the app my team has been working on. Cele (“celly”, say it correctly…) is an for app iOS and Android that lets you know of daily quirky national holidays and suggests the most fun ways to celebrate.