Posts Tagged ‘developer’

Pocketpedia Links and iOS 9

Wednesday, September 16th, 2015

In iOS 9 Apple has made opening links from Pocketpedia slightly better but also slightly worse. The good news is that linking to another app now displays a small text button on the top left hand corner of your screen that lets you quickly back track to Pocketpedia without having to go through the home screen or use a multi-touch gesture. So digging deeper into an HTML, IMDb or PDF link from Pocketpedia is faster and more natural and has a quick return.

Peter iPhone Search

Peter iPhone Search

The bad news is Twitter was abusing the ability to open links with other apps to detect what apps were installed on your device and then targeting advertisement based on this information. Apparently the list of apps checked was as big as 2,500 different apps.

Apple makes a fuss about the need to approve and control the App Store to prevent malicious behavior, yet they didn’t simply ban the Twitter app, instead they put the burden on all the other developers. We are now required to list within our app all possible link types that you might want to open.

This new information goes inside the apps info.plist file under the key LSApplicationQueriesSchemes. Luckily there is no restriction on the number of links that can be listed so far. Pocketpedia for iOS 9 has included a smallish list of the most common types that our users use, such as pdf://, epub://, iBooks:// and imdb://. The problem is that our users are a varied bunch and use all kinds of apps. So if you find that a link to your favorite app from Pocketpedia is no longer listed, please drop us a note with the URL scheme to the name of the app and we will be sure to include it in the next release.

A single person using a single app means we have to list that URL scheme in Pocketpedia for all users. If only a small percentage of users are using a unique app, soon our exception list will grow quite large. But as I said, for now there are no limits and hopefully Apple reviewers will not start complaining that we are listing too many URL schemes.

Apps not updated for iOS 9 have a little leeway of being able to ask for 50 random URL schemes. We petitioned Apple to make this the default via an Apple bug report, but it never came to fruition. Each individual user is likely to only use a few favorite apps from Pocketpedia so a lower limit such as 20 random links would have been a perfect solution and it would have solved the abuse issue from Twitter without any code changes required for other third party developers.

Out of Africa

I find it discouraging that an iOS 8 app gets better support and treatment than an app developed for iOS 9. Especially since the technology exists and is implemented to allow a small number of URLs and could have worked beautifully paired with the new exception list. But on the upside, we now get full Spotlight integration, so you can search your media directly in Spotlight.

Detecting PPC Code Before Mac App Store Submission

Friday, June 3rd, 2011

Since the Mac App Store is Intel only, developers have to submit applications that are stripped of all PPC code. Slowly more and more developers are building their applications Intel only, given that the latest versions of OS X, Snow Leopard and soon Lion, are Intel only. The Pedias rely on a large number of external frameworks, so it was not as simple as changing the build setting in Xcode. While the transition happens here is an easy command we used to find PPC code used in our applications.

find -exec file {} \; | grep "ppc"

Of course run in Terminal while inside the build directory and change Bookpedia for your app name. Should any frameworks or libraries be reported to contain PPC code, you can strip the PPC without rebuilding by using the lipo command.

lipo -remove ppc AFramework.framework/AFramework -output AFrameworkIntel

I stored these new Intel-only versions of the frameworks to be used by Xcode when building our software for the Mac App Store. Of course there is also the option of doing the stripping to the entire app after building with the ditto command (but I prefer to do modifications before Xcode’s final code signing step, even though Mac App submissions are re-signed for any changes during upload).

ditto --rsrc --arch i386 x86_64

Hope some developers with larger apps will find this useful.