App Store

Sunset for Parse

Allen Pike’s piece on the Parse shutdown is insightful, in-depth, and a great read. Marco’s response adds his thoughtful perspective.


In early 2013, I began looking for a syncing service to use in multiple iOS apps. I was one in a long list of developers who viewed sync as an add on, that sync should be as easy as adding another project dependancy. Parse added much of the functionality I was looking for. It was easy, cheap, and the company seemed to understand the needs of their customers.

It wasn’t long after I began testing Parse integration in a sample project that news broke of the Facebook acquisition. Parse promised that with Facebook’s backing, Parse would be able to grow faster and not worry about monetization. All in the name of good will for developers.

While I applauded their enthusiasm, the acquisition meant that from that day forward, Parse would be acting in Facebook’s best interests, leaving developers in second place.

Because I have zero faith in Facebook, I could not have faith in Parse as a product or a company and began exploring alternatives.

That decision paid off this week. Instead of scrambling to figure out a new backend as a service (BaaS) and migration strategy, I can instead use that time and effort to continue building new apps and making improvements to existing products.

The Parse shutdown has brought the BaaS debate back to the forefront in the developer community. That is, should developers roll their own BaaS or migrate to a Parse alternative like CloudKit?

Instead of relying on Parse, I jumped into Apple’s CloudKit over a year ago. It’s baked into Apple’s platforms and (for now) has Apple’s support. I use CloudKit as a back-end for Screenshot++ and in unannounced projects.

Allen and Marco lay out the two sides of this debate quite well. For many developers who have experience in running their own servers, this has always an easy decision. Experienced backend developers like Marco haven’t had to rely on 3rd party solutions. For them, it’s relatively easy to roll their own solution and today they’re in the clear; it’s hard not to hear the smug comments coming from atop their high horses.

For the rest of us, Parse was the solution to a problem that few app developers have the experience or resources to properly solve. I don’t view Parse as a shortcut and I don’t think the objective should be to rely on a service like Parse until you can create something better in-house.

For the 600,000 apps that used Parse, they’re in a tight spot and most of those will end up abandonware if they’re not already. To insinuate their developers should have all created custom backends is out of touch with today’s App Store economic reality.

With Parse out of the picture and the app BaaS market underserved, now is the perfect time for a new competitor to fill the void.

App Store Metadata Rejection

Screenshot++, my new screenshot management app for iOS, was submitted more than a week ago to App Store Review and they returned this week to say the App Preview video was rejected.

Specifically, Apple took issue with showing screenshots being taken in apps other than mine. The offending apps weren't apps from the App Store, they were Calendar and Maps - both built into every iOS device. I (wrongfully) assumed this would be acceptable.

It appears they're strictly adhering to the rule that App Preview footage is limited to video taken within your app and your app alone.

So how do I demonstrate to a potential customer the process of taking a screenshot? I'll have to stick with in-app instruction and text in the App Store page screenshots. It's unfortunate that I'll have to stick with in-app instruction and App Store page text. Potential customers may or may not take the time to read text on my App Store page but everyone who watches the Preview video will understand the concept from example.

This may seem trivial but I have seconds to demonstrate the app's value proposition. I cannot assume that every iOS device owner knows how to take a screenshot or even knows what a screenshot is. However, the majority of iOS users have screenshots littered through their Photo Library. For this reason, Screenshot++s App Store page isn't just selling the app, it's also for educating potential customers on why they need it. 

I broke one of the rules and had my app metadata rejected. (I believed this would be accepted. I want to avoid a metadata rejection at all costs, but here I am.) To be clear, it seems the app itself passed review but the Preview video did not. 

I swiftly removed the offending video and resubmitted. I'll now have to wait another week to go through the queue and have everything reviewed for the second time.

This is my biggest problem with the App Review system. Inefficiencies waste valuable time for both the developer and Apple. I'll explain:

The original review of Screenshot++ included the app itself, Preview video, screenshots, keywords, and app description. If everything but the preview videos was approved, why should everything have to be reviewed again if it hadn't changed?

A better approach, after sending the rejection email would be to provide the developer with a selection of next steps. Either I resubmit the app (the current and only option) or Apple provides the option to make a quick metadata change if completed within a short amount of time.

Consider a better system: I receive the metadata rejection that the Preview video cannot be approved. I then log into iTunes Connect, remove the video and press 'Update' (or something equivalent). The app then goes back to the review employee who sees the change and continues with the app approval.

The above scenario eliminates the second review, saving at minimum an hour of a review employees time, and my app is available for purchase on the App Store a full week before the current system allows.

Creating App Store Preview Videos

I've spent the better part of a day creating the first app preview video for Screenshot++, which I hope to launch in the next week or so.

Record your app in action on an iOS device using Quicktime in Yosemite, import the video footage into iMovie, create an App Preview project and start editing. Pretty simple so far.

I created a short soundtrack for the preview in Garageband and added it to the iMovie project. Export and upload to iTunes Connect. Done, right?

I uploaded the video to iTunes Connect under the "4-inch" tab. Then, I went to the "5.5-inch" tab and the preview wasn't there. Why not?

The docs reveal that you're supposed to upload a video for each iPhone resolution (that's 3). But, I don't have an iPhone 6 Plus, so now what?

After some digging, it turns out that Apple prefers videos in each resolution but will provide one version to all devices when viewing in the App Store if you only provide one. This isn't documented anywhere I could find but I'm trusting the good people on stack overflow.

Why not just export from iMovie in each resolution? That was my thought, but alas, iMovie doesn't give you that option. There is also no reasonable way to use Quicktime's screen recording feature with the iOS simulator.

So for Screenshot++ 1.0, I've uploaded a Preview view each for iPhone and iPad. We'll know after the app launches if the video is viewable on all modern iPhones.

Marketing Resource for iOS Bundles

1416851061130.png

If you've recently put together an iOS App Bundle, like I have, you may be wondering where you can find the Marketing Resources.

For iOS apps, Apple provides us with guidelines and image resources for marketing purposes. This includes assets and user guidelines for the App Store Badge, psd files for currently supported iOS devices for dropping screenshots into, App Banners, and the like.

Head over to Apple's Developer Page for an explanation of iOS Bundles. Apparently though, that's it. 

How are developers supposed to advertise their Bundles?

I tried to create and then hack an App Banner (link) using the Bundle's Apple ID. The result was a blank frame. Using the Link Maker tool returned no results for my bundle.

Let's try creating something simple - an image of the bundle and an App Store link for my website.

Since the bundle icons seem to be generated though iTunes Connect, can I download a high-res version? I haven't yet found a way. Perhaps the App Store is laying out the individual icons rather than flattening them into a single bundle icon image. So far, I haven't been able to find any information. 

iTunes Connect does provide the App Store url for the bundle. So that's one step in the right direction.

It's odd Apple has so little guidance on the subject. I'm left with two conclusions. Either developers are not intended to specifically advertise their App Bundles on their website or it's an oversight on Apple's part. I'm getting the feeling the former is true.

If you've come across anything useful, let me know at w.dyson [at] me dot com.

Cheers!

Creating iSource 2.5 for iOS 8

Tonight I finished work on the latest version of iSource APA (2.5). It supports and now requires iOS 8 and is currently awaiting review.

iOS 8 brings great new features and fixes many bugs introduced with iOS 7's interface redesign. Along with iOS 8 is Swift and Xcode 6.

The biggest features that users will notice first are Today and Sharing widgets. Shortly after WWDC14, I decided not to include support for these in apps that didn't absolutely need them. In the case of iSource, what was I going to include in a Today widget? A fancy slogan? An inspirational quote? Nope. I didn't want to take up people's time with a Today widget unless it provided real value.

Take the Clear Today widget. If you remove all the content in the app, it decides to give you a *cough* inspirational quote. I didn't ask for it but there it is. 

You also may notice a beta version of the Today widget I'm including in Bug Trackr 2.0. It tells you what you need to know while using the minimum amount of screen real estate possible.

Below, you'll see Pedometer++'s Today widget. Short and to the point, I like it.

iOS 8's Today view is still very much a UI playground and I realize developers are often scratching their heads about what to include there. Sometimes, the best thing to do is do nothing at all. 

Sharing widgets are another story all together. I would love to be able to create a resource share sheet, basically the same text entry you see in the app, but available through other apps. There would be a relatively low amount of apps you would want access to iSource's Share widget in but it could still be useful.

The problem is iOS 8's sharing data flow paradigm. The way iOS 8 works is that you select the data you want to share, tap the share button, and select the place or service you want to share to. An iSource share sheet would make sense in a scenario where the user, from anywhere in iOS, wants to add an entry, they bring up the iSource Share Sheet and enter in the resources parameters. But that reverses Apple's data flow in iOS 8's share sheets. It would be confusing to the user even if Apple approved it in App Review.

So for now, we're going to stay away from Today and Sharing widgets.


Also new in iSource 2.5 are completely redesigned resource icons. They fit in a whole lot better with the iOS ⅞ aesthetic and they're included as @1x/@2x/@3x (and @4x for then that day arrives) assets. The icon redesigns were something I had started last year when I added more assets but, since the introduction of @3x assets (which I didn't have), I decided to start from scratch on a new set.

With this version and unrelated to iOS 8 I decided to reintroduce landscape support for iPhone. This was only because of the new display sizes in the iPhone 6 and iPhone 6 plus. In the 1.0 version of iSource, I enabled landscape support because text entry was done directly in the table view. When I added the Entry Sheet around iSource 2.0, I removed landscape because springs and struts in Interface Builder didn't allow me to configure the sheet view as I wanted when displayed in landscape with the keyboard visible. With the addition of Size Classes in Xcode 6, its now possible for me to create different configurations of the entry sheet based on its size class.

Top right you'll see the traditional version of the Entry Sheet in iSource 2.5, complete with blurred background. Bottom right is the Entry Sheet in it's new landscape configuration. Nice eh? Thanks Size Classes!


At WWDC14, I was highly interested in playing around with iOS 8's new Embedded Framework support. iSource 2.5 includes the new iSourceKit framework and it's where I've put a lot of code and resources that I share between iSource APA and MLA. Without going into too much boring nitty gritty about maintaining two versions of the same app, frameworks are a godsend. For code within iSourceKit, I've been able to cut debug time in half and every minute saved debugging is one I can now spend on making great feature. Thank you Embedded Frameworks engineers at Apple!