Our BlogTips, Tricks, and Thoughts from Cerebral Gardens

My WWDC 2018 Wish List

WWDC 2018


Everyone seems to have their own list of things they want to see at WWDC, so I figured I should throw mine down on virtual paper too. I'll keep it short for you and mostly just include things that aren't on everyone else's lists.

AppStores:

  • they all get the 2017 update, adding curation etc.
  • (macOS only) allows more powerful (read non-sandboxed) apps back in the store.
  • commission rate change: 5% for apps sold via a deep link, 15% for apps sold via search/browse, 30% for apps sold via curation stories/app lists/features.
  • ability for devs to merge SKUs, i.e., combine X and X Lite into one app. Any user that had downloaded either now gets the merged version and the receipt lets the dev know which one(s) the user originally downloaded.
  • ability for users to browse all stores on any device, make a purchase, and have the app installed on a different device. I should be able to browse the tvOS AppStore on my Mac, buy a tvOS app and have it install on the family room Apple TV.
  • new badges on every app that indicate features/warnings, such as: age rating, whether or not the app is sandboxed, has passed an accessibility audit, if there's a complimentary macOS/iOS/watchOS/tvOS app, is on your wish list (which they need to bring back), etc. (Hat tip for the accessibility audit idea from Marco Arment on Under the Radar)
AppStore screenshot showing 1Password with new App Badges

iOS:

  • ability to set default apps for email, web, calendar etc.
  • add app shortcuts to Control Center.
  • better control of audio, routing and setting different volumes (ring vs media etc).
  • landscape support for Face ID.
  • multiple faces for Face ID.
  • bring the iPad keyboard to iPhone (the swipe down on a key for the alternate version feature).
  • more granular selection of contacts to allow calls from when in Do Not Disturb mode.
  • multi-user support (for iPhone and iPad).

macOS:

  • the ability to lock the dock to one screen. Having it randomly fly around all my other screens has driven me nuts for years, especially when I go to click an icon on the dock and then the dock runs to a different screen so I can't click it.
  • HomeKit support

tvOS:

  • a built-in web browser.
  • enable UIWebView/WKWebView in tvOS apps.
  • multi-user support.

watchOS:

  • complications that can update more frequently (1 minute intervals). Even if this requires user permission to update that often.
  • custom watch faces.
  • always on display.

Xcode:

  • plug-in system, at least restoring functionality that was lost in Xcode 8. I'd even be happy with just a way to restore colour to the console logs.

HomeKit:

  • when using automation to turn on a light, be able to turn it off after x number of hours without a second automation. Right now this feature exists, but is limited to 60 minutes. I have several lights that I turn on at sunset, and off at sunrise. They all require 2 automation tasks. Being able to say turn off in 8 hours, would simplify things.

Mac Mini:

  • updated Mac Mini's. Maybe even a Mac Mini Pro with Coffee Lake CPUs, Dual 10 GigE ports, USB-A and C/Thunderbolt 3 ports. Up to 128 GB RAM, 4 TB SSDs. Able to drive 3 5K displays.

MacBook Pro:

  • updated, with a fixed keyboard design. Coffee Lake CPUs, Up to 64 GB RAM, 4 TB SSDs.
  • option to include the Touch Bar and the standard function keys. I feel most of the hate with the Touch Bar was not with the bar itself, but the removal of the function keys (especially the escape key). I’d buy a MBP that included both.

iPad Pro:

  • Face ID.

I really wish I could be in San Jose for WWDC this year. It's been a while since I’ve been out with my fellow developers, so you’ll have to have a beer for me. Stay safe, have fun, and hopefully I'll see you next year!


If you've found this article interesting, please subscribe to the RSS feed and follow me on Twitter and/or Micro.blog

It would be awesome if you'd download our newest app All the Rings. It's free and we really think you'll like it!

If you see any errors, want to suggest an improvement, or have any other comments, please let me know.

Proposed Affiliate/Developer Commission Changes

Big news from Apple today:

Starting on May 1st 2017, commissions for all app and in-app content will be reduced from 7% to 2.5% globally.
Screenshot via @drbarnard on Twitter

Apple is reducing commissions paid to sites who promote our apps by 64%! That's a huge cut and they're only giving everyone involved 7 days notice.

The app economy has been tanking for the last few years. Apple must know this by now, even though they tout how great it is (maybe it is for a few big companies such as Niantic Labs, Nintendo etc). Personally I think this change in commission rate must be part of something larger, aimed to help rejuvenate the ailing app economy.

Back in June, 2016, Apple announced the first change in the percentage developers pay Apple, dropping the 30% rate to 15% but only for those using subscriptions, and only after a customer has been a subscriber for at least a year. For the most part, this would only have helped a few developers so far, since only a limited number of developers were even allowed to use subscriptions until the June changes. Those would be the Netflix/HBO type apps that are worth billions and don't need the extra help.

What I'd like to see at WWDC this year, is for Apple to announce they are finally reducing the 30% rate we pay to something more reasonable. Let's say 15%?

Assuming that's the plan, how about this as a proposed alternative? Instead of dropping the rate to 15% across the board, Apple could drop the rate to 15% for apps installed organically, and 20% for apps installed through an affiliate link. That extra 5% could then be paid to the affiliate who earned the sale. As a developer, I'm fine with that since it only helps those who help me.

I feel this would be a win-win for all involved. Developers get a much needed drop in their commission rate. Promotion sites such as iMore, touchArcade, etc will get a small bump instead of a drastic cut in their earnings, and Apple gets to keep the new 2.5% affiliate commission rate. I know dropping the developer rate isn't ideal for Apple, but it would make a big difference for the people who help keep their devices in demand.

What do you think about this proposal? Please @ me on Twitter and let me know your thoughts.

It’s Time to Transition from the App Store to the App Mall

With the recent announcement of some App Store changes, and WWDC just days away, I figured I’d better write about an idea I had before it’s too late. I’ll keep this much shorter than the version that’s been floating around in my head.

I would suggest that Apple release their grip on the App Store, and start allowing other stores on iOS/tvOS which would, essentially create an App Mall. Open it up so that anyone can create a store. These will be distinct apps developed like any other third party app, clearly branded to avoid user confusion with Apple’s App Store. I envision stores created by brands you already know: TouchArcade, 148Apps, AppShopper, Google, Microsoft, Panic, OmniFocus, RelayFM (for sponsored apps) etc; as well as new ones that will appear.

These stores would be akin to radio stations. If a person likes Rock and Roll, they tune in to a Rock and Roll station. If they prefer Jazz, they listen to a Jazz station. Every once in a while you listen to something different. We’ll have stores that focus on pro apps, stores for games, a store for writers, developers, parents etc. Users will come to know and trust the curators of their favourite stores. This plan delegates some of the curation of apps out to the community where it can be handled much better (just because of sheer numbers). It doesn’t take away from Apple’s App Store curation, rather it enables a method to better group apps and aid with app discovery. Instead of trying to fit 2+ million apps into 25 categories, there will be another layer on top to help sort.

One huge side effect to this plan is that Apple would have more control over it’s own App Store. They will be able to delist a tonne of bad apps, and stop adding new bad apps by raising the criteria that allows apps to be listed in the official App Store. If an app is ugly as sin, riddled with spelling errors, etc, they can refuse to include it in their store, just as Saks Fifth Avenue can refuse to stock substandard products. Right now, Apple has a set of rules, and if your app follows those rules it should be allowed in the store. Ugly apps should never be featured anyway, but they still come up and clutter the search results, they still show up in the “Customers Also Bought” section. With my new plan, those apps won’t show up at all. It’s my belief that Apple has to generally accept any app that follows their rules, or else they’ll start to run afoul of anti-competition laws. Since there is no other way to sell apps to users with iOS/tvOS devices than through the Apple App Store, if they reject apps based on religious beliefs, politics, bad UI, etc, they are preventing other companies from operating, and could get into trouble.

It would sort of be like Panasonic selling a radio, and then saying no Justin Bieber songs can be played on them. How long would it be before Panasonic was dragged into court by the Department of Justice? So my point here is that because Apple would be allowing developers to list their apps in other stores, they’ll be free to be more selective in their own store.

None of this affects app review, signing, pricing or privacy BTW. All apps would still go through review (though it would be more for weeding out malware or buggy software). Apps would still be signed by the developers and installed from Apple’s servers. Just as the TestFlight app can install apps that aren’t in the App Store, third party stores would also be able to use an API to trigger app installs (securely of course, apps wouldn’t be able to install other apps without the user’s explicit permission). The price of an app would be the same, and the payment would still be handled by Apple. So privacy is preserved as Apple would still be the only one to know who the customer is. Apple could still take their 30% (or now 15% in some cases, hopefully more cases soon). The third party store developer would be compensated via the already existing affiliate program. Or depending on the store, they may charge the developer for a listing, just as grocery stores charge food producers for the valuable space on the end of the aisle.

The goal of this idea is to help with app discovery. By opening up the App Store in this way, it empowers the developers in our community to help solve this major problem that’s really hurting the platform, without compromising the security or privacy of the platform that users have come to expect.

Every iOS and Mac Developer Needs a Watchdog

Today, Cerebral Gardens introduces Watchdog for Xcode. Watchdog is a helpful utility for iOS and Mac OS X developers that monitors Xcode cache files (DerivedData) and cleans out stale files before they interfere with your builds.

If you’ve been building apps in Xcode for a while, you will see the value in Watchdog instantly as you are familiar with the weird errors that can happen with Xcode. If you’re new to using Xcode, you may not have run into these issues yet, but eventually you will and that’s when Watchdog will save immense time and frustration.

A Watchdog user will no longer see these weird issues:

  • Old images that you've replaced, still showing up in your app.
  • The DerivedData folder growing continuously over time, often taking up 10+ gigabytes of space.
  • Constants/Defines not updating in the app after you've changed them in the code.
  • Localization file changes not being seen.
  • Phantom breakpoints and/or breakpoints stopping on the wrong line.
  • Xcode refusing to run a build on your device, only reporting something obscure like: "Error launching remote program: No such file or directory"

Sometimes the cause is related to your version control system updating files without Xcode noticing. Sometimes it’s random. Regardless, the result is the same: a bad build, time wasted, a frustrated developer, or even worse, an annoyed customer.

These errors can be mind numbing. Let Watchdog be your guard against these errors so you never again have your time wasted.

Watchdog gives you truly clean builds, saves time, and your sanity. It guards, protects and, most importantly, prevents.

Download Watchdog for Xcode

WWDC 2013: Ideas for Expansion

WWDC 2012 sold out in less than 2 hours, a record that had been easily predicted by many. Tickets went on sale at about 8:30 Eastern time and were sold out before most people on the west coast had even woken up. The demand for tickets was obviously extremely high, and the supply was limited to about 5000. How can Apple solve this for next year?

Of course, the first question is, does Apple even want to solve this. I believe they do. They have information they want to put into the hands (and heads) of developers, as many developers as possible. That's why they release the videos shortly after the event. That's why they've had the free Tech Talks in various cities. So yes, Apple does want to get the information out to many developers as they can. So it's to their advantage to increase the supply of tickets for WWDC.

One idea that often comes up when this topic is discussed is to have two events. Perhaps keep the first one in San Francisco and have another a couple of weeks later somewhere in Europe. The SF one would have the main Keynote for press, just like the present; the Europe one would skip the keynote but have all of the same sessions. This would temper the expectations of the press, who may be disappointed if the event were held months later without additional product announcements. The SF one would still be called WWDC, but would now actually be 'Western World Developers Conference', the Europe one would be EWDC, 'Eastern World Developers Conference'. The downside of this scenario for Apple is the increased cost, not just the direct costs of hosting an event in Europe, but the time involved in tying up Apple's engineers for an additional week (or two including travel/prep etc).

My personal suggestion is to keep it as one event, but increase attendance to about 10,000. The most common argument against this idea is that Apple likes to have a roughly 1:5 engineer to developer ratio, and they don't have enough engineers available to maintain that ratio if they double the developer attendance. I've only been to one WWDC, so this could be inexperience talking, but to me, the number of engineers there was almost irrelevant. Each session had 1-5 engineers on stage, but it didn't matter whether there were 500, 1000, or 2500 people in the audience, only the size of the room affected how many people could attend. Where the number of engineers matters is in the labs (which are more like Q&A sessions than labs). So I have an idea to increase the usefulness of the labs for everyone, while at the same time increasing the efficiency so that the same number of engineers can support 10,000 attendees.

The idea is to have attendees submit the questions that they intend to ask an engineer in a lab, to a special WWDC lab email address (along with their project source if applicable). These questions will be prescreened by Apple engineers (or even interns) way before WWDC. Some questions will be simple enough that an email response will be enough to answer them. For the rest, an appointment at WWDC can be scheduled with an engineer that can actually answer the question for the developer. In a lot of cases there will be duplicate questions that can be answered in a group session. This plan will reduce the need to have such a high ratio of engineers to developers while increasing the value of engineer and developer meetings. No more lining up to talk to an engineer that doesn't know any more about the problem you're trying to solve than you.

The only other logistic is how to fit an extra 5000 people ino the sessions. My plan there would be to expand to Moscone North and/or South, and make all of the rooms bigger. Same number of sessions, same number of engineers, just a larger audience. I heard developers this year talk about how long the lines were to get into each session, and that they weren't that long in previous years. But the consensus seems to be that Apple was just way better organized this year than in previous years and that the lines just looked longer than a massive mob of unorganized people. My point here is that Apple did a great job of moving the 5000 attendees around this year. If they increase the time between sessions a little, it should be possible to move 10,000 people around the 3 buildings efficiently.

Whatever the plan, I can't wait to attend WWDC 2013.

If you enjoy reading my blog, please follow me on Twitter, and/or like Cerebral Gardens on Facebook.

What a Week! WWDC 2012 Edition

This was my first WWDC, but it certainly won't be my last. It was a great experience and I'm going to try and share some of the things I learned over the last week. Nothing that's covered by the NDA of course.

1) It was great to finally meet some of the big wigs in the community. Drinking beer with Jeff LaMarche and the other MartianCraft guys. Hanging out with the Empirical Development guys that I've been working with for most of the last year was awesome. Getting to pitch Party Doodles to Eli Hodapp (of Touch Arcade) and Victor Agreda, Jr of (TUAW) in person was amazing. I'm sure it helped that Apple basically used Party Doodles as an example of how to do an AirPlay game correctly.

2) Probably the biggest shock to my system was the amount of walking involved. As someone who normally sits at a desk for 12+ hours a day, it was a major change to walk back and forth from my hotel 2 or 3 times each day. Why 2 or 3 times you ask, depending on whether or not I took my laptop to the sessions and wanted to drop it off at my hotel before dinner/socializing etc, or based on meetings with various people I had scheduled between sessions.

3) In most cases, you do not need to take your laptop with you to the sessions or labs. I had a completely incorrect assumption of what the labs were. Labs should be considered more like Q&A sessions with Apple engineers. They are not planned tutorials or anything scripted. They're just a chance to ask a question, sometimes with someone who may have helped build the system you have a question about. The only time having your laptop with you is probably if you need to show an engineer your code during your Q&A (lab) session.

4) For the labs, my own experience was pretty dismal in this regard. I had a few questions to ask about various topics, and each time, the engineer(s) I was talking to had no more information to provide on the issues. That being said, I heard of some people that had much more successful visits to the labs.

5) The actual sessions where amazing. Some covered brand new information about iOS 6 or Mountain Lion, while others covered older information that you might have missed. Sometimes you see something presented that's been available for a while that you just hadn't seen and you think "this will save me hours". When the session videos are released, make sure you watch as many as you can. Even if you think you already know about a topic. There are always extra little tips that are invaluable.

6) When you attend a session in person, please use some common decency and follow these four rules:

  1. When sitting down, move to the center of the row, don't 'end cap' the row by sitting in the first seat. Most sessions fill the entire room and when everyone has to fill in rows by jumping over a person sitting in the first seat, it's pretty annoying.
  2. Wait until the speaker has finished talking before running out to the next session. We all have to get to the next session at the same time, give the speaker the respect they deserve by letting them finish.
  3. Do not use a MiFi device. They jam the provided WiFi and in some cases prevented even the presenters from being able to demonstrate what they had planned.
  4. Take your trash with you. If you bring in a drink, lunch etc, just take the garbage with you when you leave and drop it in the garbage bin or recycling etc. I think they teach this in kindergarden but it appears some people missed that day.

7) Related to #2 above, the choice of hotel is important. The closer the better (or at least the less walking you have to do). But there are other issues. I only have experience with the one I stayed at this year, Parc 55 Wyndham, but I'm pretty sure I won't be staying there again next year. The room was nice, clean etc, most of the staff were nice and helpful. My issues with the hotel were

  1. the network is awful. Wifi or wired, it wasn't strong enough to keep iChat connections alive. And they charge $15/day ($50/week).
  2. the included breakfast only includes pastries, you can add eggs and bacon for $25!
  3. the elevators are extremely slow, taking up to 10 minutes to go up and down.
  4. the TVs are locked down and prevent you from adding your own input, no connecting Apple TV or your laptop for example. That made testing some changes to Party Doodles impossible.

8) Since I'm Canadian and our roaming fees are insane, I wanted to pick up a local SIM card in order to be able to use data whenever I needed. I have an unlocked phone so it should have been easy. Eventually I went AT&T, $50 for unlimited voice and text, and $25 for 1G that they said wouldn't work on an iPhone and that they wouldn't refund the cost if I couldn't get it to work. After putting in the SIM card, it took all of about 30 seconds to switch the APN using the site: http://www.unlockit.co.nz/. The AT&T network has been great the whole week (Keynote excluded, but nothing was working there).

9) J.J. Abrams. Wow. He was a guest speaker for the Friday lunch session. And boy was his talk amazing. For one, he was by far the most entertaining speaker of the week, granted his content makes it easier, blowing up stuff is more exciting by itself than NSManagedObjects being accessed by the wrong NSManagedObjectContext. But his way of presenting was great, it almost felt like it was just me and J.J. in the room and he was telling me stories from his life. It was very interesting to hear how certain ideas/shows came to be due to other events in his life, in much the same way we move from app to app where the first app may inspire the idea for the second app. I'd love to go into more detail here, but it seems even this talk is covered by the NDA. J.J., if you're reading this (maybe Google Alerts brought you here), I just want to say thanks for the awesome and inspiring presentation.

10) One last point. Since it was my first WWDC, I wasn't sure when I should be here, so booked my flight for Saturday to Sunday. Getting here on Saturday worked out well, gave me some time to get to know the area and meet up with people for drinks etc. But next year I'll leave Friday night or Saturday morning. There wasn't much happening on Saturday or Sunday as most people have already left.

I'd say WWDC (I'm not yet cool enough to be able to call it "dubdub") was a great success this year. I can't wait for next WWDC 2013! It'll sell out super fast again next year, so be prepared...

If you haven't already, please download my free game Party Doodles, like us on Facebook, and if you like to hear me ramble, follow me on Twitter.

Will iOS 4.3 Change the App Store Ecosystem?

All indications point to the imminent release of iOS 4.3, if not this week, then certainly by next week. As always with new releases, a host of new features will be included, not just for users, but also for developers.

The rumour is that 4.3 will introduce subscription pricing options to the app store. This is in response to newspaper and magazine publishers looking for better pricing options for daily, weekly and/or monthly editions. But, who says subscriptions need to be limited to publications. Apple's Terms of Services don't. More on that in a bit.

One of the challenges of iOS development is earning enough revenue to make a living. It's been said that there are two app stores, App Store A, where you sell apps with mass market appeal, hoping to generate a lot of revenue in a very short time, and App Store B where you sell apps that target a narrower audience, aiming to generate a steady revenue stream for years.

App Store A is often compared to buying a lottery ticket, and has just recently made an appearance in Dilbert.

Dilbert.com

App Store B is considered to be the more attainable, long term success strategy. Since you're aiming at a narrower target market, it helps to be able to generate recurring revenue from your users.

I've long wanted to try charging a monthly or yearly fee to use an app, something that will support the development process after the initial sale. Every other software platform allows you to charge for upgrades in order to generate some recurring revenue from your installed user base. A few apps on the App Store have phased out the original version and released a new version, with a new charge. There a few problems with this approach, a) users who buy the app just before the switch, kind of get screwed, b) there's no easy way for a user to transfer their data from version 1 to version 2 (it can be done, but you have to build in a solution, unlike normal app upgrades), c) not all users of version 1 will even know version 2 is available.

Another option is to add new features and charge for them though in-app purchases, then a user can decide if the new features are worth the extra money to them, if not, no harm, they keep using the app as they bought it.

Back to the new subscription option. With subscription pricing there will be a new opportunity to generate recurring revenue from your user base. And to the user, it will be a well defined, easily understood method. $x per time period. Just like paying your monthly phone bill, or a yearly magazine subscription. You can cancel at any time, or keep paying and take advantage of all new features as they're released. For developers, you now have recurring revenue. Earnings to enable you to continue to maintain and support the app, while still feeding your kids.

There's no indication yet what the options will be from Apple, but it's a good guess that the same pricing tiers we're using now will apply, and that you'll be able to select from a variety of time periods, likely: weekly, bi-weekly, monthly, quarterly, yearly. As an example, you'll be able to charge $0.99 a quarter, instead of a one time fee of $2.99. If the user doesn't like your app, they save money. If they like the app, and continue to use it, you'll break even after 3 quarters, and earn more for the entire length of time the user uses your app.

The largest obstacle I foresee moving to this model will be the blow back from customers. The current app ecosystem has bred a sense of entitlement where users (not all, but a lot), feel they deserve an app, all future updates, full support etc, all for the low cost of $0.99. For most developers, and most apps, this isn't sustainable. Using a subscription will help solve this. As more of us developers begin to use this model, customers will begin to accept it and most likely actually prefer it, since they'll know exactly what they're getting and for how much, and their apps will constantly improve at no additional cost. And, all things considered, they'll still be getting their apps at a ridiculously low price.

Update: Apple officially released the information on subscriptions today. Subscription term lengths are: weekly, monthly, bi-monthly, quarterly, bi-yearly or yearly. Thanks Apple for giving developers more opportunity to become profitable!


iOS 4.3 is currently available as a beta and thus is under an NDA. Nothing I discuss here is covered under the NDA to my knowledge as there's been no official word about subscriptions other than the now public iTunes Terms and Conditions. If you feel I have disclosed something in the NDA, please let me know and I'll edit the post accordingly.

TestFlight Your Apps

You've been working on your new app for ages and it's finally ready for beta testing. Prior to iOS 4.0, it was a considerable pain in the neck to get a build on to your testers devices. You needed to package up your apps and ad hoc profile, send them to each tester, and then they needed to use iTunes to install the profile and app on their device. It seemed like an art more than a science getting an app installed, never mind an updated build later. It was a very clunky system, and it didn't always go smoothly.

With iOS 4.0, Apple made it much easier to install test apps on a device. It's now possible to install profiles and apps without going through iTunes. Using XCode's Build and Archive option, you can create an .ipa file that embeds the ad hoc profile. Just put the .ipa file on a web server, (or your public Dropbox folder), and send the link to your testers. They can install the build by clicking the link in mobile Safari.

You're still required to collect your users UDID's, add their devices to your developer account and create an ad hoc profile that includes their devices.

Last week, TestFlight, a new service for distributing your test builds to your beta testers, went live. TestFlight promises to revolutionize the way developers beta test their apps, and after testing it out for a bit, I'm pretty sure they're going to do just that.

The free service, found at testflightapp.com, allows a developer to invite people to become a beta tester. The tester creates an account through the web site in Mobile Safari on their device, and then they register their device with the system. This process involves installing a configuration profile (different from an ad hoc profile, but listed in the same area on the device's settings). This gathers the device UDID and reports it back to the server. A tester can register more than one device. The tester, and her device(s) then show up in the developer's account. As a developer, you can export the UDID's of all your testers and import them into Apple's iOS Provisioning Portal. One issue I found here though, is that if you attempt to import a file of UDID's that contain a record that you've already added to the Portal, it will reject the entire file, instead of just ignoring that record.

Once you've imported all the new UDID's into the iOS Provisioning Portal, you can update your ad hoc profile to include all of your testers. Then, use it to create a test build of your app. You still need to use XCode's Build and Archive Option, and then use it's sharing wizard to create the .ipa file (all in all, a simple process, more details here: http://iphonedevelopment.blogspot.com/2010/05/xcode-32-build-and-archive.html).

Next, you upload your .ipa file to the TestFlight web site, and select the testers you'd like to notify of the new build. TestFlight emails each of them a link to a page that lets them install the build easily.

TestFlight lets you see how many times the .ipa file was downloaded (though, not by whom for some reason). I had one person delete it from their phone and redownload it, and it counted as another download. So a list of 5 people, with 5 downloads, doesn't really mean they all downloaded it. But it will likely be close.

I tested this entire process with some extremely non-technical people, not one had an issue. They were all able to create their accounts, register their devices, and install my test app with ease.

If you need more beta testers, TestFlight offers a recruitment tool. You can start recruiting random people through Twitter, your web site, or wherever. It's just a link you post. When people sign up to be a beta tester for you, you can accept or reject them based on whatever criteria you like.

Overall, I'm very impressed with the initial service offering TestFlight has. And, remember, it's entirely free (for now) for developers. They are charging for enterprise accounts.

I do have to point out one concern I have with TestFlight however. During my limited testing of the service over the last couple of days, I uploaded a few builds, sent them out to some testers, including myself, and then deleted the builds. When I went back to one of my test devices, I still had the link open in Safari to do the install, for a build that I had deleted in the TestFlight dashboard. So, I tested, and tried to install the build, that should have been deleted. It installed perfectly. This is my concern, because I had deleted the build! Which means, that TestFlight, is not actually deleting the bits of the builds you tell it to delete, it's just removing them from your dashboard. Whether or not you consider this acceptable is up to you (and your personal level of paranoia) . But remember, that when you upload your .ipa to TestFlight, you're letting unknown people view and test your ideas (yes, the TestFlight people can view and run your .ipa files, if they so choose).

If you are concerned, you can use Hockey to manage your beta installs. It's not as easy to manage as TestFlight, but you con trol everything on your servers so it's arguably more secure.

You can even mix and match some of the TestFlight features (UDID collection, recruitment etc), and then deliver the actual builds via Hockey.

Paranoia aside, TestFlight is excellent so far, and will change the way you deliver your test builds to your testers. Down the road, they plan to support additional features, such as adding analytics so you can view what your testers tested and for how long.

Dev Tips & Tricks

Today I'm going to cover some useful tips and tricks. These are presented in no particular order, and are pretty much unrelated to each other. Hopefully you'll find some, or all of them useful.

1. Regarding the upcoming iPad 2

Reports are starting to surface that the next version of the iPad will support a retina type display. Apple will no doubt repeat what they did with the iPhone 4 and double the resolution (4 times the number of pixels). This makes it easy to support old apps on the new device by employing pixel doubling.

But, you can start preparing for this now! For every iPad image you use, include a higher resolution (double sized) image with the @2x suffix. And for icons, include a 144x144 (double 72x72) icon. I've included a 144x144 icon in all my iPad apps since the iPhone 4 was announced, betting on Apple doubling the iPad resolution. It's cheap to do, and if the predictions are wrong, there's no harm in having an unused icon.

As a sub tip, you should include the following sizes for your icons: 144x144, 114x114, 72x72, 58x58, 57x57, 50x50, 29x29

2. self.var vs var

In your classes, when use the following syntax:

DWClass.h

@interface DWClass : NSObject {
    NSObject *myObject;
}

@property (nonatomic, retain) NSObject *myObject;

DWClass.m

@synthesize myObject;

You're telling the compiler that your new class DWClass will have a property called myObject, and that it should create setMyObject (setter) and myObject (getter) methods to access that property. And that those methods should handle your retain/release cycles for you. Any other objects that need to interact with your myObject property, will do so by like this:

dwClass.myObject // (assuming dwClass is an instance of DWClass)

And this will actually call the appropriate setter/getter for the myObject property, which in turn interacts with the myObject instance variable of the dwClass.

Inside the DWClass however, you can access the property like this:

self.myObject

And the same setter/getter methods are used.

Inside the DWClass, you can also access the myObject instance variable directly just by referencing it. DO NOT do this. If you do that, you're not using the setter/getter methods, which means you're not automatically handling the retain/release calls. This is a surefire way to create hard to find bugs in your code. Plus, there are other problems with doing this. If down the road, you need to do something special whenever that property is accessed or updated, so you ditch the @synthesize and create your own setter/getter methods, you're now going to miss even more than the retain/release calls, you're going to miss whatever else you've added.

This entire tip also applies to non-object properties. Even if you're using a standard int as a property, always use the self.variable syntax to access it. It's just good practice and will save you headaches down the road.

3. Keeping your secrets, secret

Often when you're accessing other services, Twitter, Dropbox, your own servers etc, you may need to store passwords, API keys, etc in your code. It's dead easy to just have a constant like this: @"MySuperSecretKey" and be done with it. If you do that though, you may as well post the secret on your web site for all to see. Since, it's trivial for a bad guy to extract your secret from the compiled code they download from the App Store after your release. This is a bad thing. In the case of Twitter for example, some spammer could put your secret key into a rogue app that spam blasts users. Every one of those tweets will say it was sent by your app, and your legit app will be blocked pretty quickly. Your users will be locked out until you submit a fix and have it approved by Apple, say goodbye to two weeks of sales, not to mention, all the bad reviews you'll receive for selling a non-functioning app.

So, keep your secrets secret, use some encryption inside of your app to encrypt your keys etc. It doesn't have to be complex as the bad guy usually just looks for low hanging fruit (unless they are specifically targeting you). You can use one of the many encryption libraries available, or even roll your own if you're so inclined.

4. Ensure the App Store knows you support multiple languages when you do so

This tip comes from a mistake I made in version 1.0 of the Cruze app. The app supported English and French from the get go, but it was done by detecting the language of the user via code and loading the correct set of files for the primary language. This worked great and was way less work than using Apple's recommended method of localization for every nib etc.

One problem though, once the app was released to the store, the only supported language listed in iTunes was English. Because I used my own language detection iTunes Connect didn't detect French. I fixed this in 1.5 by using Apple's localization on a small dummy text file. One that I don't actually use for anything in the app, but that is enough to trigger the language detection tools Apple uses.

Update: see Ovogame's comment below for an even better way to fix this issue.

5. AppName_Prefix.pch

There's a file in your XCode project named AppName_Prefix.pch (where AppName, is your app's name). This file is included at the top of every source file in your project. It's a great place for you to store any constants you need across your app.

6. A Better NSLog()

A common method of debugging is to add NSLog() calls throughout your code. The messages are echoed to the screen as the code runs and you can see what's happening, giving you hints as to what's causing bugs. When you're finished however, and you want to do your final build, all of those NSLog() calls remain in your final build and all of those strings are available for anyone looking through your binaries to see. Who knows what secrets you might disclose.

Instead of using NSLog(), I use DebugLog(). This is a tweak of a function I’ve seen others use, based on the answer here: http://stackoverflow.com/questions/300673/is-it-true-that-one-should-not-use-nslog-on-production-code.

Add this to your AppName_Prefix.pch file:

#ifndef DebugLog
#ifdef DEBUG
#define DebugLog( s, ... ) NSLog( @"<%p %@:(%d)> %@", self, \
	[[NSString stringWithUTF8String:__FUNCTION__] lastPathComponent], __LINE__, \
	[NSString stringWithFormat:(s), ##__VA_ARGS__] )
#else
#define DebugLog( s, ... )
#endif // DEBUG
#endif // DebugLog

Now, replace all of your NSLog() debugging statements with DebugLog(), and define DEBUG in your debug configuration (sub tip 2: go to your Project Info, Debug configuration, search for Preprocessor Macros, add DEBUG).

After this, use DebugLog() all you like, and the strings are skipped over in your Release and Distribution builds. You also have the added bonus of having the function name and line number included with all debug statements now, making it clear what's generating the messages.

7. *.dSYM files

Whenever you build your app, XCode will output the *.app files, as well as a *.dSYM file. For Debug and Release builds, you can just toss/ignore the *.dSYM file. But for your distribution build, that you're going to submit to the App Store, make sure you keep the .dSYM file. You'll need this later, to analyze crash reports. I'll go into more detail on this in a later post, just know you need to keep the files. For the impatient, you can read more on this here: http://www.anoshkin.net/blog/2008/09/09/iphone-crash-logs/

8. Push Notification Certificates

If you have an app that uses push notifications, you need to generate a certificate with Apple, one of the first steps, is to create a Certificate Request file (CertificateSigningRequest.certSigningRequest), that you send to Apple. Keep this file. When your certificate expires, you'll need to request a new one. You can reuse the same Certificate Request file and skip the first few steps.

9. [object release]; object = nil;

With NSObjects, when you're done with them, you call release to reduce the retain count and let the system know you no longer need it. When that retain count hits 0, the system free's the object and releases the memory allocated back for use later.

It is common practice, to set the object to nil after you call release. This prevents a possible crash later, if you attempt to call a method on an object that has been freed. That's because if you try to call a method on a nil object, the system just ignores it, no error, all is good (or is it). If you don't set the object to nil, then it will still point to the memory address that was allocated for that object. There's a chance that object is still there (if something else was using it and increased the retain count for example). In that case, calling a method on that released object, will still work. But if that memory had actually been released calling the method would cause a crash.

This is why developers often set the object to nil, to prevent that crash in the case of a bug. But, this doesn't fix the bug, it just hides it from you. So, I subscribe to the second school of thought you shouldn't set the object to nil. If you have a bug, let the app crash while you're developing and you'll be able to find and fix that bug. When you no longer have any crashes, you'll know you're (closer to being) bug free, and that you haven't just masked your bugs.

Open Source, the GPL, and the App Store

I am a believer in the idea that a large subset of humanity enjoys helping one another to be successful, and that they become better themselves in the process. One way this occurs is with the Open Source movement. People that write software not for the profit that can be made with the software, but to give it away so that others can use it, as an end product to accomplish a task, or even to use as part of another project. This enables the next person to get a jump start on what they're working on in order to become successful faster than they would have been if they'd had to start from scratch.

Ideally the next person becomes a link in a chain so that others can benefit from their work and become successful themselves. Everyone does their part and everyone benefits.

Not all Open Source products are equal however. Just because someone releases their code as open source, doesn't mean you can do whatever you want with it. There is always a license of some sort attached to the code that governs what you're allowed to do. The Open Source Initiative site lists 67 different licenses that they've approved as meeting the existing community norms and expectations of what an open source license should be. Before we go any further, let me clarify that I am not a lawyer, I don't even play one on TV. So you should always consult your own legal council when dealing with legal matters.

Of all of the open source licenses, there are a few that are used more than others. The GNU General Public License (GPL), the Apache License, BSD License and the MIT License are the most popular. The latter 3 are very similar and impose the least restrictions on users of the code they license. The GPL imposes some very specific implications on users of the code it licenses and is the reason I'm writing this article today.

In simplified terms, the Apache, BSD and MIT licenses allow you to use the code they cover in other products and allow you apply a license of your choice to the new product. It doesn't have to be an open source license and so you're not required to provide the source of your product to others. You do have to include the appropriate copyrights for the source you've used that was created by others, and you do have to accept the fact that the source is provided to you AS IS, that there's no warranty of any kind given by the original creators of the code you're using.

The GPL however forces you to use it as the license for your new product. In this way, it has been described as a virus license since it effectively reproduces itself onto your product, and limits what you're allowed to do with your product. That is, you're forced to release the source code of your new product, and you must allow others to redistribute your product for free, in both source and object code. The philosophy behind this is that if you're benefiting from the work of others, you should be forced to share your work in the same way so that others can benefit. These restrictions make the GPL incompatible with the App Store, which means, as an iOS developer, you should avoid using any code that is covered by the GPL.

The reason that GPL code is incompatible with the App Store is the requirement that someone receiving the product be able to redistribute that product to someone else. Since all apps in the App Store have Digital Rights Management (DRM) applied to them, users are unable to directly share the apps with others. Because a developer is unable to give that right to the user, they are effectively barred from distributing their app through the App Store.

Just yesterday, this became an issue on the App Store as the popular app VLC was pulled by Apple due to complaints that it's presence on the App Store was a violation of the GPL. Even though the app was available for free, and the source code to the app was made available at http://git.videolan.org/ for anyone that wanted it, the DRM issue overrules and thus, no VLC for you.

As a user this is disappointing since the app allows you to play media files that no other app on the App Store, or built into iOS devices can play. But as developer, this is extremely alarming and should cause you to audit all the libraries you've used to ensure none are covered by the GPL, else your apps could suffer the same fate as VLC.

What's most disturbing about all of this, is that it seems as though, this is really just a silly technicality. The fact that a user is unable to share the exact binary they downloaded from Apple doesn't mean they can't share the app with a friend. The user can share the app just by sharing the iTunes link to the download (which is free), or alternately, provide the full source code. So the spirit of the GPL is still possible with the App Store, just not the letter of the GPL.

It would be possible for the Free Software Foundation (creators of the GPL) to release an updated version of the license to make it compatible with the App Store, but since they feel that all DRM is inherently evil, it's unlikely that will ever happen. Arguably, it might be possible for Apple to make DRM optional for certain apps, but that would require fundamental changes to the iOS architecture and might introduce security holes that make it easier to pirate apps. I don't see either side making any compromises here so your best bet, is to just avoid all GPL code and find (or create) alternatives that are licensed under the Apache, BSD, or MIT licenses.

Discussion - Reducing App Store Piracy

This week, I'd like to throw something out for discussion. These are ideas that have come up in the course of real life discussions with other app developers. I need to preface this by saying that I have not implemented any of these ideas, and that I'm only putting the ideas out there to encourage you to think about and discuss alternatives.

It surprises me that in an ecosystem of 99 cent apps, piracy rates are still incredibly high. For this article the assumption is that as an iOS developer, you are able to detect at runtime, if your app has been pirated. There are multiple ways to do this, but the technical details of which are not required for this article so I'm going to skip them.

One of the requirements to install a pirated version of an iOS app on a device, is that the device needs to be jailbroken. If the device has been jailbroken, then certain security features will have been disabled. This makes it possible for apps to do things on the device, that Apple doesn't allow under normal circumstances.

This means, that a normally well behaved app, could be made to 'go rogue' when it detects that it has been stolen by the user. For instance, a stolen version of your app, could make a phone call to a charge per call phone number that charges the cost of the app to the users phone bill, therefore recovering the cost of the app for the developer. Similarly, the app could send a premium text message out, also charging the cost to the user's phone bill.

Now, I'm not proposing that you actually build this into your apps, as it's almost definitely the wrong way to go about building up your business1. As iOS developers, is it not part of our job to educate users on the dangers of using pirated apps? The above ideas can be used in the same way we've warned against pirating desktop apps due to the dangers of viruses and other malware. Common users should be encouraged to live in Apple's walled garden as is indeed a great place for users and developers to be.

1 A user that has pirated your app is still a potential customer and needs to be treated as such.

Discussion - Apple's App Store Policy Against Name Squatting

Today I'd like to discuss Apple's recent policy change with regard to app name squatting. If you're unaware of the policy, Apple says you must now submit your binary for an app within 120 days of reserving the name. If you don't submit a binary, you'll receive warning emails with 30 and 7 days remaining in your 120 day grace period. At the end of 120 days, if you still haven't submitted a binary, the app is automatically deleted by iTunes Connect and you're forbidden from using that app name again in the future.

The idea behind this policy is likely to prevent the ridiculous name squatting environment the exists with domain names. Personally, I don't believe that Apple has come up with a great solution to the problem though. 120 days isn't long enough for an independent developer working in his/her spare time to create a good quality app. And there's a known work around anyway1, that just forces you to do an extra 5-10 minutes work per name to reset the 120 day count. So what has been accomplished? It makes it awkward for someone to register a tonne of app names and just sit on them, since the 5-10 minutes add up fast.

I propose that there is a better solution. Instead of an arbitrary time period to submit an app, why doesn't Apple limit each developer account (that is, per $99 fee), to an arbitrary number of incomplete apps. Lets say 10 for example. In my hypothetical world, you can squat on up to 10 names for each $99/year. Making app names cost about $10/year, similar to domains. But the domain ecosystem is a disaster you say. Well the difference is that with domains, there's a whois database. Everyone can find out who has registered a domain, and contact them in order to generate a sale. There is no current way to find out who has reserved an app name, and thus no way to buy the rights to a name. Which means, there is no market for buying and selling app names; crazy domain name ecosystem averted. The only people reserving app names will be those who plan to use them.

I'm sure there are problems with my proposal also, or that you have an even better solution. Please add to this discussion here.

1 Rename the app that's about to expire to some gibberish, and recreate a new app with a new SKU and the original name you're reserving. Credit: Daniel Jalkut

Three’s Company: Multiple XCode Versions Living Together Peacefully

Apple is making fantastic progress with iOS. They continue to release firmware updates and betas at a frequent pace, and with each new release, developers must download and install a new version of XCode compatible with the new firmware. Managing the various versions and their associated firmwares can be a challenge. In this article I'm going to give you a couple of tips that will hopefully help.

It's not uncommon for developers to have multiple versions of XCode installed on the same system in order to support development/testing across a wide range of devices and firmware versions. XCode by default installs in /Developer, and it is common practice to install the latest beta version in /DeveloperBeta. Those testing XCode4 know its default install folder is /XCode4. Personally I found this to be messy and inadequate.

My preferred setup now is to create a directory /XCode and install each version of XCode underneath using the version info as it's base folder name. Currently this looks like this:

/XCode/3.2.3_4.0.2
/XCode/3.2.4_4.1b3
/XCode/xcode4_dp2

When installing XCode in this fashion, you’ll find that in some cases, you won’t be able to install/debug a build on one of your devices because of a mismatch in firmware versions. For example, the XCode 4 Developer Preview 2 was released before firmwares 4.0.2 for iPhone and 3.2.2 for iPad. So if you’ve updated your devices to those firmwares, you’re now unable to use XCode 4 to directly install or debug.

There is a simple fix however. You just need to create symlinks from one version of XCode to another. Assuming you’re using a layout similar to what I’ve detailed above. If you look under /XCode/xcode4_dp2/Platforms/iPhoneOS.platform/DeviceSupport you’ll see folders for each version of iOS that you can install/debug on. 3.2.2 and 4.0.2 are obviously missing. If you’ve installed the latest version of XCode 3 with support for those versions, you can make XCode 4 work with them.

In terminal, issue the following commands to create the required symlinks:

ln -s /XCode/3.2.3_4.0.2/Platforms/iPhoneOS.platform/DeviceSupport/4.0.2 \
	/XCode/xcode4_dp2/Platforms/iPhoneOS.platform/DeviceSupport
ln -s /XCode/3.2.3_4.0.2/Platforms/iPhoneOS.platform/DeviceSupport/3.2.2 \
	/XCode/xcode4_dp2/Platforms/iPhoneOS.platform/DeviceSupport

Similarly, If you’re using the 4.1 beta 3 firmware on your iPhone, you’ll need XCode 3.2.4_4.1b3 installed, and can then enable support for that firmware version in XCode4 also:

ln -s /XCode/3.2.4_4.1b3/Platforms/iPhoneOS.platform/DeviceSupport/4.1\ \(8B5097d\) \
	/XCode/xcode4_dp2/Platforms/iPhoneOS.platform/DeviceSupport

If you have your XCode versions installed under a different directory structure (/Develper, /DeveloperBeta, and /XCode4 etc), you’ll just need to tweak the above lines to point to the correct folders.

A similar trick can be used to allow you to use a base SDK of 3.1.3 or earlier, which is no longer included in the latest versions of XCode. Just create links under the /XCode/Platforms/iPhoneOS.platform/Developer/SDKs to an older XCode that does include support for the SDK you need.

If you have any tips to improve upon this, see an error in what I’ve described, or otherwise have anything else to contribute, please let me know.

Some Thoughts on Tweetie

Everybody else seems to have a blog, so I suppose Cerebral Gardens ought to have one too. This will be written by me, Dave Wood, the founder and developer.

The issue that has compelled me to finally write something is the whole Tweetie upgrade pricing issue. First, I want to say that I always try to look at an issue from every side, though I'm not always successful at that. In this case it's pretty easy, since I'm both a developer and a user. Next, I'll admit that while I did buy Tweetie v1 for iPhone, I barely use it. I use Tweetdeck most of the time because of it's quick account changes. And Twitterific the rest of the time. Bought Tweetie just because it worked during the twitpocalypse. I do use Tweetie on my Mac exclusively (with the ads 'cause I like the ads, very relevant to me).

So, the issue with Tweetie v2 being a fully new version with no upgrade path is a tough one. Largely because developer’s choices are limited due to some of the restrictions imposed by the App Store. Enough people are writing about how to fix the store, so I'm going to present options that may work with the current setup of the store.

There are two main problems to deal with here (again, not counting the App Store issues). 1. Users expectations for free updates. 2. Developers needs for a sustainable business.

Regarding users expectations for free upgrades: I believe there should be an expectation for free upgrades for some length of time whenever someone buys software. That time is up for discussion. With a $1500+ Adobe Suite purchase or even Apples $69 iWork product, I believe that time period should be at least a year. With a $3 app, perhaps it should only be 30 days. Although I believe current users are expecting longer. Anyone expecting, or offering, lifetime updates is insane. That's obviously not sustainable.

But the expectations do exist; whether or not they should. Developers (myself included) need to start setting customer expectations to match our plans. Stating what the upgrade path will be in our app description for instance. Just stating something like 'free upgrades for 30 days' etc. As I type that I have to laugh. With a 14-20 day review process 30 days doesn’t seem like enough. 3 months perhaps.

John Gruber of Daring Fireball fame (whom I read religiously) compared buying a $3 app to a $3 cup of coffee. I don’t believe this is a fair comparison. The only thing they have in common is their price. A cup of coffee is a physical item, actual water, coffee beans, cream and sugar maybe, as well as a paper cup, and a plastic top. A person has to physically take your order, prepare the coffee to your taste, and hand it to you. The whole process takes a minute or so of someone’s day. If 1000 coffee’s are ordered at the same time, it takes a lot of people to serve them up in the time expected by the customer. Compare this to apps. There’s nothing physical with an app, not even a disc with iPhone apps. Once the app is made (and of course there is a cost there), it doesn’t cost much more per app ordered. It costs the developer (almost) the same to develop the app whether it ends up selling 10 copies, or 10 million copies. A closer comparison would be comparing apps to songs. We pay about $1.29 per song now. Imagine the uproar if songs were $3 each. Heck, I think $1.29 is expensive, but I pay it.

Continuing to compare to music, consumer’s expectations have been set; people buy a song or CD and they’re done. They don’t expect to get the same song again in a new format if it comes out; people joke about how many times they’ve bought the White album. They don’t expect to get an extended, or remixed version of the song for free if one comes out. The point here is that expectations of users can be set to be very low.

Perhaps this is what Atebits is starting to do. They’re reducing the expectations of their users, drastically. Possibly too fast, hence the uproar.

I've read that Atebits has said they would like to offer an upgrade path that gives current users a discount, but that it's not an option with the App Store. Here's one way it can be done. (This isn't pretty and I wouldn't recommend anyone else do this; further below is an option that could work for the rest of us, with time to plan).

Set Tweetie v1 to $999. No sane person would buy it at that price. If they do, Apple will refund it, (and hopefully not ding you the full refund price as indicated in the dev contracts). Then submit v2 as two apps, an update for v1 users, and a new app for $3 with text in the description to set the users expectations correctly. V1 users get the update they expected and also have their expectations for future updates set to nil. When v3 is ready, v1 and v2 are removed from sa le, v3 is submitted as a new app.

Regarding problem 2, the sustainable business: obviously developers have to be paid for their work, and continue to be paid for building upon that work. I’m going to assume that the incredibly low app prices aren’t going away; even if most developers raise their prices, there will always be bottom feeding app spammers (such as Brighthouse Labs) selling crap for $0.99.  So Atebit’s plan to release Tweetie v2 as a separate app actually makes sense (after setting expectations correctly).  But lets take it a step further.

I believe that we should be selling our software based on the time the user will use the app. Pick a value you want to charge per month of use, in this case, we’ll go with $1/month. Adjust these rates when/if prices in the App Store in general change. If you estimate your app has a 1 month life for the user, perhaps a game that will become boring/be completed in that time period, charge $1. If it's good for 3 months, charge $3. If the app is like Tweetie and useful for a year, charge $12. From here, we get my other possible solution (for the rest of us).

This option requires planning, so it's too late for Tweetie. If you expect a 6 month life of the app from v1 release to v2 release, price the app at $6. Each month drop the price of the app by $1. When v2 comes out, price it at $6 again. V1 goes to free, but is unsupported, or could even seize to function if that’s made clear to the user before they buy it. This is giving your users a set cost per month of usage. It’s not perfect, but much closer to what people expect, and it's a sustainable business model for us developers. I believe this will work extremely well if lots of us start using the model. This could likely be implemented via in app purchasing, by charging for each month of usage.

I’m going to stop here, without a final conclusion since I consider this just part of an ongoing discussion. I look forward to continuing to discuss these issues further and working with others in the community to solve these problems (among others) while creating successful businesses.