Lloyd's Video Analysis Tool: Now in the Mac App Store

Yes, Lloyd's Video Analysis Tool, an app I started over two years ago was just accepted by Apple and is now in the Mac App Store. It took three tries to get it in and although there was much frustration and anxiety associated with the first two rejections, I learned a great deal about many things, some of which I'll try to summarize briefly in this post.

First, some words of thanks to two people in the LiveCode community who helped me get through the last grueling quarter mile on this project: Klaus Major and Jacqueline Landman Gay. I also need to send special thanks to Sam Rowlands of Ohanaware. Apple found a bug in my app the second time they reviewed it which led me to a very confusing journey into the world of Apple's sandboxing approach to apps. I was finally able to understand the problem well enough to come up with a workaround thanks to their help. While on the subject of Ohanaware, they make a fantastic product called App Wrapper 3 that I heartily endorse. It "wraps" your app with Apple's developer certificates and automatically gets the app ready for uploading to Apple's iTunesConnect. I'll be purchasing a yearly subscription from here on out at a very reasonable cost of only $49.99. (Please note that was an unsolicited and unpaid endorsement!)

A Question I Had Long Pondered: Do I Even Want to Submit to the Mac App Store?

To be honest, I knew submitting to the Mac App Store would probably be a hassle given my previous experience submitting iOS apps to Apple. One has to figure out the whole "Apple certificate thing." Plus, I knew already that it was going to be a struggle to figure out how to then add the proper certificates to my Mac app because, unlike iOS apps, LiveCode does not provide a way to do it as part of the standalone creation process. (As it turned out, App Wrapper 3 made this step incredibly easy.) I also didn't know if my $99 annual Apple developer fee for iOS apps would count for Mac App (as it turns out, it did). In anticipation of all of this, I had done some research on "alternatives to the Mac App Store" and found a company called FastSpring. I like the company and so far they have provided great support. Now that my app is in the Mac App Store, I'm reviewing my options at this point. I still might offer the app for purchase at FastSpring also, assuming it doesn't violate some Apple policy. I already know that FastSpring is fine with me selling on the Mac App Store. FastSpring also did not require the Apple developer certificates, though I knew this would tremendously impact my sales as the app would then not be "recognized" by anyone Macintosh as coming from a "trusted" source due to way Apple's Gatekeeper software works. My point here is that FastSpring has been very easy to work with and flexible. I think further exploring a relationship with them will teach me more about the business side of app development, which I think my students will be interested in knowing more about.

But, I'm getting ahead of myself in telling this story. To back up, I was pleasantly surprised to be able to successfully acquire the needed development and distribution certificates from Apple. And, thanks to App Wrapper 3, I was able to easily add these to my app and produce a downloader file suitable for uploading to iTunesConnect. So, I decided I would just to submit a "lite" version of my app to Apple and sell the app itself on FastSpring.

I was also ambivalent about what to do for Windows users. Almost all of the problems reported by my beta testers over the past year have been about the Windows version. I didn't want to sell something to people if I wasn't confident it would work. All my development and testing of the app was on the Macintosh for the Macintosh, but it's obviously very easy just to also export a standalone version of the app to Windows with LiveCode. And, it did work for Windows users most of the time (as my students who are Windows users reported). So, a few months ago I decided that I would sell only the Macintosh version but the purchase would also come with a free (though unsupported) copy of the Windows version. That is, I would make it clear you were buying the Macintosh product and the "toy inside" (to use a breakfast cereal metaphor) was a free Windows copy. I felt this was ethical and met my own standard of "truth in advertising."

Mac App Store Rejection 1

First, I want to point out that I received feedback from Apple within about two hours of submitting the app the first time. Despite the fact that the app was rejected, I was very grateful for the quick turnaround.

Two reasons were given for the rejection. First, it appeared to the reviewer that it was a demo app and these are not allowed by Apple. I knew that going in and actually made the case in my "Notes to the Reviewer" when I submitted the app that this "lite" version was not a demo in that one could use the app to do real work even though the app intentionally had limited functionality. However, the reviewer still felt I was in violation of Apple's policy, but also gave me feedback that this objection could be overcome simply by indicating that another app would have to be purchased for complete functionality. Even though I felt had already done this, I apparently put this information in the wrong place. OK, so that objection could be easily surmounted.

The second reason for rejecting the app was that "the app enables additional functionality in a non-standard manner. Enabling features within the app with mechanisms outside of the App Store is not permitted." The reviewer is referring to the "unlocking" strategy I created on my own (click here to read about that). I obviously wasn't surprised that this strategy was termed a "non-standard manner," but I didn't think it would be a show stopper. I think the key phrase is "outside of the App Store" because obviously Apple wants all purchases to be made inside so that Apple gets their share.

After sleeping on it, I decided to just go ahead and submit a fully functional app to the Mac App Store. I submitted it around Noon last Sunday.

Mac App Store Rejection 2

Apple responded that they had rejected the app at about 10 pm Sunday evening. Three reasons were given: 1) the app wasn't "sandboxed appropriately"; 2) there was some discrepancy in how I named the app in various places in the submission process; and 3) "Apps that exhibit bugs will be rejected." Reasons 1 and 2 were easy to deal with, but a bug? The reviewer was nice enough to send me a screenshot of the error with a description of what s/he was doing at that moment, which was very helpful. Here's the screenshot:

This screenshot shows LiveCode's "Bug Report" dialog box that I wisely incorporated into the app some time back. Unfortunately, the Apple reviewer did not actually choose to send me the bug report. So, I spent the next day trying to recreate the error.

I actually was able to recreate the error rather quickly given that I knew where to look based on the reviewer's feedback. It was a "division by zero" error, something I had seen before when the video didn't load properly. The reason for the error is that I use a little custom formula that uses the duration of the movie in the denominator. If the movie doesn't load, this value is 0, hence the error. But, I had never seen the error before under these circumstances. Thus began a three day journey into discovering why.

Troubleshooting the Bug

Although I'm tempted to really get "into the weeds" at this point, I'll just jump to the cause and the solution. This is again where I need to thank Klaus, Jacque, and Sam. Without their timely responses to my calls for help, I would still be scratching my head. (If you want to read my detailed description of the error and the troubleshooting that ensued with Klaus, Jacque, and Sam, you can click here to read all about it in my posting to LiveCode's Mac OS forum.)

The problem was rooted in how Apple's sandboxing technology works. I already knew that all "apps were islands" in iOS and Mac OS, so I wasn't trying to write anything outside of the app's sandbox area. But the app does need to read outside the sandbox to get the path to the project video. This path is then stored correctly within the walls of the sandbox. But here was the really confusing part - the app successfully "found" the video outside of the sandbox, but it wouldn't load it. I just couldn't wrap my head around this because the user obviously had successfully been able to get the video to work when the project was first created. Why wouldn't it work now? I became even more confused when I discovered (after a few hours) that if I created a second video analysis project from scratch using exactly the same video, the first, older project would now work! But, if I quit the app and restarted, both stopped working ... unless I created a third project from scratch that also used the same video.

So, I figured the problem had something to do with Apple's sandbox technology. I initially put the blame on LiveCode's Player object. Sam explained to me what was needed to solve this problem, namely the programming some some key "entitlements" into the to allow it to access to the user's main area on the hard drive. Unfortunately, Jacque explained that this solution wasn't possible with LiveCode. I am so grateful to have learned this from Jacque because I likely would have spent many more days trying to figure it out. The solution I finally used is really just a workaround. I discovered that I could "reconnect" an old project to the video simply by asking the user to "confirm" the location and name of the project's video using LiveCode's "answer file" command. It was easy to include in the script the name of the video plus opening the video's enclosing folder in a dialog box. The user simply had to click to confirm the video. This re-established the link to the video and the link was sustained as long as the app was running. Yes, this added a little bit of inconvenience to the user, but there really was no other way to solve the problem.

Third Time's a Charm

I made the modifications along with a few last minute improvements to other parts of app, then submitted my third version to iTunesConnect around 1:00 pm on Friday. I tried to do other work after that, but I found myself checking for email from Apple every few minutes. As the afternoon rolled into the evening, I began to think those earlier speedy turnarounds from Apple were flukes. And, this was the Friday before Memorial Day weekend - the unofficial start to summer here in the USA - so I worried I might have to wait until Tuesday at the earliest to get a reply.

Interestingly, I mentioned to my wife around 7:30 pm that given that Apple's headquarters were in Cupertino, California, perhaps the reviewer was also on "California time" making it was only 4:30 there. I joked that the reviewer would say to him/herself "Maybe I'll review just one more app before my long weekend" with my app being the next one in line. Well, at 7:49 pm, I received an email indicating that my app was now "In Review." Then, at 8:50 pm I received word that my app had been approved!

Giving Out Free Copies

I've also updated the Web site for "Lloyd's Video Analysis Tool" where people can download the free version of the app to check it out before purchasing. This free version still has the "upgrade" feature that unlocks the app with the right secret code to give it full functionality. As I long planned, this will be my way to give out free copies of the app to people of my choice, such as my beta testers, all students and faculty in the College of Education at the University of Georgia, and definitely to Klaus, Jacque, and Sam. I designed the free version so that it would likely be more than sufficient for use by my colleagues who are requiring some sort of video analysis by their students as a course requirement. Having a functional, free version that teachers could use was important to me. I'm not worried about making money on this app, but then again, I'm not opposed to it either.

Final Thoughts

There is so much else I learned that I could write about here. And maybe I will since I took good notes (as always). My understanding of Apple certificates is clearer to me than before, though this still remains fuzzy. This process, at least to me, is about 5% intuitive and 95% memorization (hence the need for good notes). This is the kind of process one tends to learn by repetition. Fortunately, I have several other apps I'd like to wrap with certificates so that Gatekeeper will "trust" them when I ask my students to download and install them.

Now you might be asking how you can get a free copy of the app. Well, if you buy me a beer or two (or three) the next time we meet, that might do it. But, given that the app only costs $7.99 you will probably save quite a bit of money by just buying the app outright!