Andy Molloy

Today I am proud to announce that BabyGrow 2.6.1 is now available! Outwardly, this is the “iOS 7” update, fixing a number of issues on iOS 7 and updating the UI to fit a little better with Apple’s new design vision. The entry editor has also been improved, adding support for copy and paste and other niceties. And, of course, I fixed a number of known bugs.

Under the hood, BabyGrow has been thoroughly modernized. The majority of the UI has been reworked to take advantage of storyboards and auto layout. A lot of dead code from much earlier versions has been removed. Much code has been reworked to take full advantage of the modern Objective-C runtime. These changes won’t make a huge difference for BabyGrow’s users, but they are important nonetheless. Less of my time will be spent dealing with outdated techniques, workarounds for very old versions of iOS, and so on.

These under-the-hood changes are so significant, from my perspective, that I was very tempted to call this BabyGrow 3. It definitely has the feel of a major new version to me. However, most of that will never be seen by users of the app, and outwardly this is a pretty incremental update. Therefore, I decided to stick with just bumping the minor version number.

So, why 2.6.1 and not 2.6? Well, 2.6 was actually available for several hours yesterday. There was nothing actually wrong with 2.6 itself, but I forgot to upload the updated icon to iTunes Connect when submitting the app update. I didn’t notice this oversight until 2.6 became available yesterday morning. Unfortunately, you cannot update the App Store icon (or the screenshots, for that matter) once the update has entered review. The only way to update the icon is to submit a new binary, which is just what I did. Aside from the version number, 2.6.1 is identical to 2.6. It is only the App Store metadata that changed.

When I realized my mistake, I fully expected the App Store would continue showing the older version of the icon until after Apple’s holiday break that starts this weekend. That wouldn’t be the worst thing in the world, but I wasn’t too happy about it. Fortunately someone on the App Store review team apparently took pity on me and moved the update through the review process in less than a day. I should note that I did not request an expedited review. I did mention in the review notes that only the App Store metadata had changed. At any rate, whoever made that happen, I really appreciate it!

If you’ve got an iPhone and you’ve got a little one whose growth you’d like to track, go get it!

Update: Otto has been updated and is now available again. Go grab Remote and Antenna!

Over the weekend, I released a minor update to Otto’s Remote which fixed a crash that, while a bit off the beaten path, was probable enough that at least one of my users encountered it¹. There was one change to Remote: a one line fix for the crash. Before submitting, I tested the same binary destined for the App Store, as I always do. At the time, it worked. Unfortunately, something happened between submitting the update and it being approved.

The most likely change being iOS 7.0.3, which came out in that time period. Regardless of the actual cause, when Remote 1.3.1 was released, I immediately began receiving reports that the app was complaining that users were not logged in to iCloud. I gave the usual advice of logging out and logging back in to iCloud. It is a pain, but in the past it has solved 90% of the problems that have been reported to me. I also tried it myself, and was distressed to discover that, this time, it did not help.

I immediately removed Otto’s Remote and Otto’s Antenna from the App Stores. I have no interest in selling a broken product.

Then I set about to figure out what went wrong. My first step was to test the binary I had submitted to the App Store, signed with an ad-hoc certificate. This is the same process I went through before submission, in fact I didn’t even recreate the binary but used the copy I keep archived of each release. This same binary which was working fine a week before could no longer access iCloud. This is what makes me believe the problem is new to iOS 7.0.3.

Regardless of where the problem came from, though, I needed to fix it. A look at my iPhone’s console log revealed that the app’s request to use iCloud was being denied due to not having the proper entitlements. But the entitlements were fine, and were of course unchanged from before. I tried a number of things, regenerated provisioning profiles for example, but nothing seemed to make a difference.

Then, on a whim, I changed the app’s entitlements to hard code my team identifier prefix instead of letting Xcode fill it in for me². Suddenly, Remote began to work again. This made very little sense to me, so I dug in to see what was different between the working and non-working app bundles. Unsurprisingly, the embedded provisioning profile was identical. There was no sign that anything related to my team identifier prefix was any different.

However, CodeResources inside _CodeSignature had changed quite a bit. Of course there were usual differences in the checksums for xib files, which is to be expected. But there were also two whole new sections, files2 and rules2, which hadn’t been there before. There is a brief mention of these two new sections in a thread in the developer forums (here). The gist is that these two sections form a new resource seal. The Apple engineer providing that information specifies that this is for OS X 10.9, though, and there is no mention of iOS 7.

Regardless, I had a working build, so it has been submitted and is awaiting approval. As soon as Apple approves it, I will release the update and make both apps available on the store again.

I have not seen any other reports of apps failing to access iCloud on iOS 7.0.3 and it is unclear what, if anything, I’ve been doing wrong with Otto’s Remote. I do not think very many apps depend on the iCloud key-value store as heavily as Remote does. Perhaps apps are failing to access the kv-store, but people aren’t noticing? Or perhaps most people hard code their team identifier prefix in their entitlements file, and have been getting these new CodeResources sections already. Unfortunately I’m not sure that I will ever know.

A possible lesson here: If Apple releases an update to their OS between when you submit your app for approval and when it is ultimately approved, even a sub-minor update like 7.0.3, it is probably a good idea to hold off on pressing that “release” button until you’ve verified it still works. In this case, I had set things up to automatically release the update on approval. I won’t do that again.

Since version 1.3 still works, I attempted to use Apple’s new iCloud download version settings to make 1.3 available to current customers who had already updated to 1.3.1. The tool works by providing developers a list of all versions of their app, with a checkbox next to each one. Versions with the checkbox marked can never be downloaded by end users, while any version without the checkbox marked is eligible. When the user goes to download the app from the Purchases section in the App Store app, the theory goes, the App Store app will download the most recent unchecked version of the app that can run on the current device. It is not possible to mark the version which is currently available in the store as ineligible for download. It is, however, possible to do so if the app has been removed from the App Store, as is the case with Otto’s Remote. When I discovered that, I had hoped the App Store app would allow current customers to download version 1.3. After several hours, the App Store app did stop letting me download 1.3.1 but instead of offering me 1.3, it simply stated that the app was not available anymore. I still had some hope that this was a data propagation issue, and 1.3 would eventually become available. Unfortunately it has now been more than two days and nothing has changed. This feature did not work as I had hoped and I filed a bug with Apple. It is unlikely it will even get looked at before 1.3.2 is released, but hopefully they will see how useful the behavior I was looking for would be and fix it at some point in the future.

To my existing customers who downloaded 1.3.1 and are now unable to use the app, I sincerely apologize. I am not trying to point fingers here, though it probably reads that way. I accept that there may have been more I could have done to prevent this issue from happening. But I wanted to share this information, both so my customers know what is going on and hopefully to help any other developers who may encounter a similar issue. I will do my best to try to prevent something like this from happening again.

Thank you for your patience.

I’m putting on the finishing touches of new versions of Otto’s Remote and Antenna. One of the primary features of these updates is localization. The good folks at iCanLocalize are providing French, Italian, German, Spanish, and Simplified Chinese translations. One or two other languages may also be coming in the near future.

BabyGrow is also available in a small number of languages, but for it I never had the marketing material translated. This was probably a mistake, one which I am not going to repeat with Otto. And of course, if I am going to have the marketing copy localized, then it makes sense for the screenshots to be localized, too. For Remote, I provide four screenshots. Four screenshots across at least six languages is a lot of screenshots - and a lot of work to put together. So, I set about to try to simplify the process as much as possible.

First, I wanted a way to have dummy data to populate the screenshots. So far, I had been setting up scripts on the various Macs in my home before taking the screenshots, removing or renaming actions I actually use for ones that I hope are more appealing to a broad audience. Then, once screenshots are done, I go back and set things up the way I actually like them for my daily use.

Fortunately, both Remote and Antenna are designed to allow different backends, replaceable at compile time. This is an artifact of a time early in development when I hadn’t yet settled on using iCloud for communication. A few weeks ago I was considering getting rid of this extra layer of abstraction since it introduces a bit of busy work from time to time, but I decided not to and now I know it was the right decision. I created a new backend which simply loads a set of static data from a plist. This dummy backend is enabled by a new build configuration in Xcode. BabyGrow has a similar mechanism.¹

Data taken care of, I still needed a way to produce 24+ screenshots for Remote. I recalled reading about using Instrument’s UI Automation for the task a few months back. After a bit of searching around, I found what I was looking for. Jonathan Penn put together a set of scripts which helps automate this task and put them on GitHub. Of course, the UI Automation script needs to be customized for each app. This was an interesting and frustrating experience, but within an hour or so I had a script to produce all of the required screenshots for the iPhone version of Remote. Unfortunately, I had some trouble getting things working in the iPad version:

So, it appears to me that UI Automation is currently completely nonfunctional on the iPad. (ADN)

Then, a while later:

Hey, so what I said earlier about UI Automation on iPad… Yeah, forget I said it. Ahem. (ADN)

Turns out, I am ashamed to admit, the current iPad version of Remote does not appropriately support the accessibility interface. Not only does this hinder potential users with vision difficulties, but it also prevents UI Automation from working. I corrected this oversight, which benefits both me and users of Voice Over. That taken care of, I was then able to automatically produce a set of screenshots for Remote on both the iPhone and iPad. Excellent!

I was still not satisfied, though. The actions in the dummy data were not localized. As nice as it is to have all of the UI translated, the user data being in English was still a bit jarring, especially for the Simplified Chinese screenshots. To handle this, I took all of the strings from my dummy data and sent it off to iCanLocalize. I then added code to localize the dummy data plist. The last piece of that particular puzzle was the screenshot demonstrating that arguments can be passed to scripts. The string entered in the arguments text field was hard coded in the UI Automation script. I updated the script to grab the appropriate translation instead.

Now all of the screenshots are produced automatically and are fully localized. This left one last detail: the carrier string in the status bar. I honestly hadn’t thought about it too much until I recently heard someone talking about an app having a custom carrier string in its screenshots². I neither wanted to advertise ATT by using raw screenshots from my iPhone, nor have plain old “Carrier” from the simulator. So back to Google I went, and I turned up this gist which allows you to replace the carrier string in your app. I added this to the screenshots build configuration and set it up to use my initials (ASM) for the carrier string.

Finally, after all of this, I can automatically produce a full set of attractive, localized screenshots from both the iPhone and iPad versions of Remote.

That leaves Antenna. Currently I have a single screenshot for Antenna with some text describing what it does. I haven’t been too happy with that solution, but honestly there is so little UI in the app that there’s not much to show. After thinking about it for a while, I decided to try to show instead of tell. It is, after all, an image, not a block of text. I haven’t finished it yet, but I am working on showing the app “in action” with a split screen (think old TV and film “telephone” scenes). I will likely be using PlaceIt, which is a great tool. I probably won’t be automating this for now, but it’s only six or seven screenshots so not as much busy work as the screenshots for Remote.

I’m looking forward to getting the new versions of Otto’s Remote and Antenna out the door soon, and am happy to have gotten this part of releasing new versions largely automated. We’ll see if it actually translates to more sales outside of the US!

Update 11/1/13: BabyGrow is no longer up for sale, and I am back to working on it. It turns out I wasn’t ready to let it go yet, after all! I’ve been working hard on a new update which will mostly be fixing several issues with iOS 7. There might be one or two new features in there, too!

BabyGrow was my first, and for a long time, only self-developed app on the App Store. It’s never sold especially well, but it does what it does very well and I’ve always been proud of it. It’s helped that I used the app myself so much. I “ate my own dog food,” as they say. But, my kids are getting older. My eldest, while still just skin and bones, is developing well enough that we are no longer so concerned about his growth. I don’t find myself using BabyGrow much anymore, outside of working on updating it.

And over the last several weeks, I’ve come to realize that BabyGrow has been holding me back. Instead of working on something clever and new, something more pertinent to my current life, I’ve been spending my limited free time mostly on BabyGrow.

I realized that I have been holding BabyGrow back, as well. There is a healthy market for apps aimed at new parents. I’ve kept a keen eye on BabyGrow’s competition over the years and think that frankly, when it comes to tracking the growth of young children, BabyGrow blows everything else out of the water. Sure, it’s not as pretty as some of the more recent offerings, but it is far easier to use, more stable, and doesn’t depend on a web service that could disappear next month. Put in the hands of an able designer and backed by a decent marketing budget, I firmly believe BabyGrow has potential to do reasonably well. But I cannot do those things for it myself, at least not right now.

So, I am putting BabyGrow up for sale. This was not an easy decision for me to make. I still have many plans for the app, many features I’ve wanted to add. I’ve started work on a new user interface, one which would feel right at home on iOS 7. It was the first product I have actually put out there for people to buy. It’s my baby. Sometimes, though, you have to let go.

Earlier this evening, I listed BabyGrow here on Apptopia (BabyGrow is no longer up for sale, see the update at the top of this post). I sincerely hope that a suitable buyer picks it up. I may not be able to keep up with it anymore, but I think the app has a lot to offer and hate seeing it stagnate. If you know anyone who might possibly be interested, a developer who also happens to be a new parent perhaps, please pass this along.

Otto’s Remote is all about making things happen. You can make things happen with a tap. You can make things happen when crossing a geofence. And you can make things happen from certain other apps using x-callback-url.

Otto’s Remote exports its functionality to other apps via a simple command, which will trigger a specified action. The URL looks like this:

otto://x-callback-url/action?computer=[Computer Name]&action=[Action Name]

Otto’s Remote will try to find an action matching the given action name for the given computer name, and if it succeeds will fire the action. Neither the computer name nor the action name are case sensitive¹.

You can also include the standard x-callback-url success and failure parameters.

That’s all there is to it!

Otto’s Remote and Otto’s Antenna are now available in the Apple App Stores! Click here for Otto’s Antenna and here for Otto’s Remote.

Update: As of version 1.3, you can also pass arguments to scripts via x-callback-url.

otto://x-callback-url/action?computer=[Computer Name]&action=[Action Name]&argument1=[arg1]&argument2=[arg2]...

You can pass as many or as few arguments as necessary, just keep incrementing the argument number. Note that the argument number takes precedence over the order the arguments appear in the URL. So, argument1 is always passed to the script before argument2, even if they are reversed in the URL.

In his recent post Screens on Screen, Andy Baio says

… stop hiding your imperfect and incomplete ideas for years. Stop collecting them in your head, like dying butterflies in a glass jar. It’s always better to let them fly.

It occurred to me that I have a number of stalled projects, sitting in private repositories, that I will almost certainly never ship. After reading Andy’s post, I have decided to move some of them to public github repositories. I’m not sure who it will benefit, but that’s really not the point, is it? Aside from the experience gained from starting the projects, I’m certainly not benefiting from them. Perhaps, though, some fresh developer will find them and learn a bit about how (or how not!) to do some things.

The first such project is Lil Jukebox, an app that allows young kids to listen to a selection of music chosen by their parents. While I normally prefer to target the most recent versions of iOS, I initially set this project up to target iOS 3.1. The idea was that parents could install it on old 1st generation iPods which were sitting in drawers gathering dust. While I eventually gave up on that (because iOS 3.1 - really, ugh! and it didn’t appear Apple would approve of an app supporting both iOS 3.1 and the then-new iPhone 5), I think that decision is reflected a bit in the code.

There are a few more, and will likely be several in the future. I will try to continue to follow Andy’s suggestion and, rather than letting such projects die like butterflies in a glass jar, I’ll let them fly.

Update: Otto’s Remote and Otto’s Antenna are now available in the Apple App Stores! Click here for Otto’s Antenna and here for Otto’s Remote.

Recently I’ve hinted a few times that I am working on a new project. Now that I’m putting on the finishing touches, I’m ready to let the world know. So, without further ado I am pleased to introduce Otto’s Remote!

Otto’s Remote, along with its companion Mac app Otto’s Antenna, allows you to execute Automator actions, Applescripts, and even Unix shell scripts on your Mac at home from your iPhone, anywhere you go.

In addition, with Otto’s Remote you can set up Geo Triggers, which will set off an action on your Mac when you take your iPhone to or from specific locations.

How is this useful?

To help demonstrate how Otto’s Remote can be useful, here are a couple examples of how I have been using it in the past few months:

• Fellow developers of iPhone and Mac apps are likely familiar with the Mac app Tokens. Tokens is a fantastic app for managing promotional codes for App Store apps. Unfortunately, being a Mac app, it is difficult or impossible to use when you are out and about. I wanted a way to use Tokens to generate a promo code for people I encounter, on the spot, without having to wait until I got home. So, I created an Automator action which launches Tokens¹, tells it to generate a new promo code, then emails it to me. Now, if I’m out and I want to give someone a promo code, I can use Otto’s Remote to trigger that action and, moments later, have a Tokens link in my inbox which I can forward on to the intended recipient - almost instantly.
• For my day job, I work from home on an iMac supplied by my employer. My work is kept on an encrypted DMG. While I have the iMac set up to require a password to exit the screen saver, and it’s unlikely I’ll ever have someone break into my house and try to access the machine, I prefer to dismount the encrypted DMG when I’m not home. However, I frequently forget to do so. So, I created an Applescript to attempt to dismount the DMG and set up Otto’s Remote to execute that script whenever I leave home.
• I haven’t actually done this, but my wife just suggested it: You could create an Automator action to play your theme music, and set it up to trigger that action whenever you get home. I think I’ll set this up now, once I figure out what my theme music is!

I’m sure there are plenty of other potential uses for this that I haven’t even thought of. If you have some ideas, I’d love to hear about them!

Interested?

I’m looking for help testing Otto’s Remote. Also, while the app is clearly aimed at power users, I want the first run experience to be as smooth as possible. Even if you don’t want to do any full-on testing, I would appreciate having a few people try installing Otto’s Remote and Otto’s Antenna and give me feedback on how easy the first run experience was. You need to have an iPhone and a Mac that stays on all the time. If you’re interested, please let me know by emailing otto@ottosremote.com.

Even if you’re not interested in testing Otto’s Remote, please sign up below to be notified when the app is released. The mailing list is managed by MailChimp, and I will only ever send you one or two emails. Otto’s Antenna and Otto’s Remote are now available, so the mailing list is now closed.

Jared Sinclair wrote about his disagreement with Apple’s messaging for iOS 7 in his recent post, Apps are content, too. It’s an interesting take on what has come out of Cupertino this week, and you really should go read it.

Unfortunately, I think it’s bullocks.

I tried very hard to sympathize with Jared, after all he is one of the minds behind Riposte, one of the most frequently used apps on my phone. But after sleeping on it, thinking about the WWDC sessions I’ve watched, and using iOS 7 on my main phone¹ I found I simply could not agree.

When I read Apple’s marketing copy, I do not get the sense that they expect every app to use Helvetica Neue Ultra Light on a white background. Instead, I see a call to rethink the way we differentiate our apps. Use more of the screen for presenting content, and less of it for branding. Instead of chrome, the way apps present the user’s content and allows them to interact with it will be what sets them apart.

Jared linkes to a piece by John Gruber, Twitter Clients Are a UI Design Playground, to bolster his argument. I believe John’s post does just the opposite. In particular, John writes

Twitter is such a simple service overall, but look at a few screenshots of these apps, especially the recent ones, and you will see some very different UI designs, not only in terms of visual style but in terms of layout, structure, and flow.

Layout, structure, and flow. Even if you buy the argument that Apple wants all apps to have the same style (I don’t), I’ve seen no suggestion that these three other things are somehow set in iOS 7. Twitter clients (and ADN clients) still have plenty of room to be UI design playgrounds.

I also don’t believe Apple would be providing us with some of the incredible new tools present in iOS 7 if they expected us to all create identical apps. There is so much new for us to use. Apple isn’t stomping out creative UIs, they’re fostering them.

On the same marketing page Jared quotes from, Apple also says this:

Simplicity is often equated with minimalism. Yet true simplicity is so much more than just the absence of clutter or the removal of decoration. It’s about offering up the right things, in the right place, right when you need them. It’s about bringing order to complexity. And it’s about making something that always seems to “just work.” When you pick something up for the first time and already know how to do the things you want to do, that’s simplicity.

It seems to me that what Apple really wants us to do is think long and hard about every aspect of our apps. Don’t throw in a fancy textured navigation bar just because it looks good. Either justify its existence, or throw it out.

Jared may not see it this way, but to me Riposte has one of the most iOS 7-ish UIs currently on my phone. No chrome. Content is king, taking up the entire display. It fits perfectly, even though I have it set up to use Avenir Next and Auto Dark Mode. Because everything on the screen is there for a reason. That sure seems to me to be what Apple wants us to be doing.

Here we are once again patiently awaiting WWDC and the iOS 7 announcements that will likely be made there. I haven’t done this in a while, but sometime back I wrote my wish list for iOS 4. Back then, I was hoping for what I called Simple Springboard to make iOS devices easier and safer for little fingers. Apple has since addressed almost everything on that list, though not in the way I imagined and, frankly, not as completely and elegantly as I think Apple is capable of.

Most of the items on my list were implemented with the Restrictions system, which allows a user to enable particular restrictions on a device. Enabling and disabling restrictions requires a trip to the Settings app and entering a passcode. This works fairly well, but even temporarily disabling a restriction requires launching the Settings app, navigating two layers deep to the Restrictions page, entering the passcode, then disabling the particular restriction. When you’re done and want to re-enable the restriction, you have to repeat all of those steps. For many of the restrictions, this is fine. But there are several actions which I would like to restrict on devices while my kids use them, but I wish to perform often enough that the current mechanism is burdensome.

It’s possible Apple thinks the problem is solved, but I would respectfully disagree. Here are my original wish list items, along with details about where the current system falls short, even if the basic problem has been addressed.

Be restricted to a set of user-specified apps. All other app icons would not appear at all.

The Restrictions system handles this by allowing a parent to specify the maximum app rating for apps displayed on the Springboard. This is fine as long as all of the apps you want your children to have access to are appropriately rated, and that you don’t have any exceptions you would like to give them access to regardless of the rating. For example, for my kids I set this to the 4+ setting. The vast majority of the apps they use are in that group, but there is at least one glaring exception: the YouTube app. There are obvious arguments for not allowing my children access to YouTube, and I am perfectly familiar with the potential risks involved. However, my boys enjoy watching clips from classic Sesame Street and other similar material that I fully approve of. Because the YouTube app is rated 12+, I can’t both lock them down to the 4+ rating and give them easy access to YouTube. Within the current Restrictions system, a list of Exceptions (or is that Additions?) that lets me state that I wish a set of apps to be available regardless of what the App Rating restriction is set to would solve this.

Disallow deleting apps – the whole “jiggly apps” mode would not exist at all.

There is a restriction to prevent deleting apps, and it works quite well. Preventing “jiggly apps” mode is impossible, though, and kids can always rearrange apps on the Springboard. Adding a restriction to prevent rearranging apps would help here.

It should be relatively easy to switch from the “normal” Springboard to the Simple Springboard – perhaps an app icon.

Enabling and disabling Restrictions mode involves navigating the Settings app. This isn’t horrible, but it involves enough steps that many parents might just forgo the whole thing and risk handing the device over unrestricted. Worse, your restriction settings are not saved if you turn restrictions off entirely. Any time you want to re-enable them you have to reconfigure the restrictions to your liking.

Even without implementing all of my Simple Springboard idea, adding an easy way to enable restrictions without having to reconfigure them every time would be a major step in the right direction. iOS has changed since I wrote my original list, and there are a handful of new options for where this switch could live: on the Lock screen or in Notification Center, for example. My top pick would be in what is now called the Accessibility Options menu which appears when you triple tap the home button. In addition to Voice Over and Guided Access, there could be a Enable Restrictions button.

On the other hand, quitting the Simple Springboard should require some complex action, such as entering a user-specified code. If this action starts, but is not completed in a certain (relatively short) period of time, the user should be sent back to the Simple Springboard.

Exiting restricted mode now requires a trip to the Settings app, and entering a passcode. That’s not bad, except that it leaves the rest of the Settings app accessible to little hands. Far better would be a system level mechanism, allowing the Settings app to be protected when restrictions are enabled. Again, there are a handful of places this could go. Pulled down from the top of the screen, in place of Notification Center. In the Accessibility Options menu mentioned above. I’m sure Apple could come up with an elegant solution which bypasses the Settings app.

Apple’s Restriction system goes in the right direction, but doesn’t quite get there. A few changes are all that’s really needed to get it close to the Simple Springboard I described before. To recap:

• Allow some mechanism of picking specific apps to either appear or not appear when Restrictions are enabled. I think a good approach would be the current App Rating setting, plus an Exceptions (Additions?) list of apps to include even if they are not in the appropriate rating group.
• Add a Rearranging Apps restriction, alongside the current Installing Apps and Deleting Apps restrictions.
• Store restriction settings even when Restrictions are disabled entirely.
• Provide a more convenient method of enabling and disabling restrictions, preferably without launching any app .

There is one idea Apple came up with that I had not thought of, and it’s pretty great. Now that my kids are a little older, I am (mostly) happy handing them an iOS device in restricted mode, but when the boys were younger I would have greatly appreciated the Guided Access feature. A parent can launch one of their kid’s apps, put the device in Guided Access mode, then hand it over and know that their child will only have access to that app. It’s even possible to specify controls to disable, keeping kids out of settings and sales screens. This is really fantastic, but it is an Accessibility feature so many parents may not be aware of it. iPhone toting parents of very young children should definitely take a look at it.

That’s about it for my “as a parent” wish list. As a developer there are a few more items, but most of them have been covered elsewhere. As always, I’m sure Apple will have some exciting new stuff for us, even if we don’t get everything we want.

Several weeks ago, Yahoo! released their new Weather app, Yahoo! Weather. The app is quite lovely, featuring full screen photos overlaid with the weather information. When you scroll down, the photo blurs and shifts upwards. You can switch between locations by dragging from left to right, and there is a parallax effect as you do so. If you haven’t seen it, you owe it to yourself to check it out. If you don’t have an iPhone, here’s a pretty good YouTube video that demonstrates the app.

I fell in love with this app immediately after installing it. It’s visually appealing, and everything moves with the silky smoothness we expect from the best iOS apps.

Playing with it one day, I decided I should try to see if I could replicate some of the core design features. I also realized I had the perfect testbed for such an experiment: BabyGrow. I spent some time over the next several evenings and weekends seeing what I could do. The video below demonstrates the results (if you don’t see the video, click here to see it on YouTube).

This is not a complete implementation of BabyGrow, and I don’t know whether it will live beyond this experiment, but I think it turned out pretty nice. It mimics the background photo, including the various effects applied to it as you scroll around. The table view will snap to the header, charts, and top of the main data section. I spent more time than I care to admit making that snapping feel just right. And, of course, it runs silky smooth on the iPhone 5 (I confess I have not yet tried it on any other iOS device).

The experiment was really enjoyable. I got to solve some interesting challenges and hope to apply things I’ve learned in the future. However, there is a lot of BabyGrow that would need to be rethought to make it fit this design. Plus I have another project I really need to finish and ship. At this point, I really don’t know when or even if I would ship a version of BabyGrow using this design. I just wanted to show off what I’ve done, plus send a big “Thank you!” to the Yahoo! Weather app team for inspiring me to do it.