From an email I received from Apple Wednesday morning:

We recently announced new, more affordable iCloud storage plans. As a thank you for being a current iCloud storage plan subscriber, we’ve increased your storage plan and you will be receiving a refund based on the reduced plan price.

[...]

Your plan has been upgraded from 15 GB of total storage at $20.00 a year to 20 GB at just $10.99 a year.

[...]

NOTE: This annually priced storage plan is only available to current iCloud storage plan subscribers. You may cancel or downgrade from your device at any time. If you choose to change to one of our new plans, you won’t be able to switch back to this annual plan.

Nice of Apple to refund current subscribers and automatically move them to the new plans. Nicer that they allow us to stay on the annual plans we're accustomed to instead of forcing us into month to month payments.

That said, seems like annual plans should be an option for everybody. Month to month charges are annoying, even small ones. And while I may still have my annual plan now, if I ever need more than 20GB of storage I will be forced into month to month payments as well. Which is probably exactly what they expect and want to happen.

This morning was the big September Apple event. In the lead up, and in the past, this event has often been referred to as the "iPhone event". This year however, while Apple did introduce 2014's iPhone lineup, it was clear from the start that it was not the main focus.

From what I could make out between live stream outages and over the voice of the Mandarin translator, which was mistakenly overlaid on the main feed, Apple rushed straight into iPhones, skipping their usual lead up of numbers and statistics. The first things we saw, not surprisingly, were the two new iPhone models, the 6 and the 6 Plus.

iPhones

I'm excited about the new iPhones. I stand by my own past admonitions that 5.5 inches is far too big, but 4.7 seems like an acceptable leap, especially with the nice new gestures they've added to make reaching the top of the display easier. The improvements to the camera, 240 FPS slo-mo, A8 & M8 chips specs, improved display, etc. are all welcome upgrades, but the biggest news for iPhones is of course the new Apple Pay system. Using the new NFC antennas in the iPhones 6 and 6 Plus, we will be able to add our credit cards into our phones and pay at participating stores by simply holding the phone near the NFC sensor and authenticating via Touch ID. I'm slightly regretting backing Coin now, but oh well.

Unfortunately, none of my wishes from yesterday seem to have been answered. While we can't be fully certain at this point since it isn't mentioned anywhere, leaks suggest that Apple likely still hasn't revved the RAM. The camera has been improved in general, but since they made no mention of improvements in shooting at night I think we can assume it's still about the same.

The memory intervals just confuse me. The iPhone 6 starts out at the same 16GBs of memory for $199 that the last few baseline iPhones have begun with, but the step up model for $299 leaps all the way to 64GB. There is no model of iPhone 6 or iPhone 6 Plus which comes with 32GB of memory. So why keep 16GB around at all? Particularly with 240 FPS slo-mo videos and 43MP panorama shots, 16GB of memory is a ridiculously low level. And while many customers will reduce the impact of these huge files by turning on the "Optimize iPhone Storage" setting, recall that the free iCloud storage plan is still limited to 5GB. It stands to reason that many of the same customers who don't want to pay a premium for an iPhone with more storage will also be opposed to paying for extra iCloud storage, so storing all their photos and videos in the cloud is not an option.

If you go all the way to the bottom of the lineup, you'll find the iPhone 5c hanging around at a single storage capacity of 8 gigabytes. That Apple is keeping such a low level of storage around astounds me. Even more so because people having open space on their devices is in fact in Apple's own interest. Many of my friends here in Tucson take months and months to update their iPhones to the next OS simply because when they try they are informed that their devices do not have enough storage to download the update. If Apple would just give them the extra storage, as the company most certainly has the ability and resources to do, then they could increase the speed of their upgrade numbers. But maybe those numbers are so high already that Apple doesn't really care. Regardless, I'm hoping for a mid-year upgrade that moves 32GB storage levels back into the lineup, and gets rid of 16 completely. Maybe they're just trying to dump inventory.

All in all, I'm looking forward to the new iPhone 6. I think it's a great upgrade, and I'll be in line at the Apple Store on the 19th to pick one up for myself.

Apple Watch

What turned out to be the main event, the rumored iWatch is finally confirmed and out in the open. Surprisingly though, they decided to name it "Apple Watch" instead of "iWatch", a choice which I disagree with.

The Apple Watch is quite an impressive device, boasting a full color touch display, a "digital crown" (the spinner on the side of classic watches which you would use to wind them in the past and is now used as a clever way to navigate), inductive charging, and much more. I won't go into much detail on the device here, as there are better sources to find that, but I'll just give my initial impressions.

I think the device looks great, and has massive potential, but I also have some concerns. While it has Apple's usual beautiful design expertise, I find it still looks somewhat bulky for my tastes. That said, it's not massive like some "smartwatches" out there, and I've also only seen it in pictures and videos, so maybe it's size won't bother me when I try it in person.

Beyond the size of the device, I think my reserved enthusiasm stems mostly from a nagging fear that the device's battery life will be less than optimal. As everyone who watches keynotes regularly knows, Apple loves bragging about the battery lives of their devices. During the Apple Watch announcement however, the only time anything near battery was mentioned was when they discussed the charger. Toward the end we got a small nugget when Tim Cook implied that we would need to charge the device nightly. If that's true then I'm honestly okay with that, but only if the device truly lasts the entire day. If the watch dies at 8:00 each night I will be vastly disappointed with it.

My trepidation is also fueled by the fact that the Apple Watch really seems to have made no compromises. Leading up the event, conjecture was made that there would be no screen, that it would controlled by spinning the outside of a circular watch and the screen would not be touch sensitive, or that it wouldn't even be a watch at all. The only way we thought Apple could do it all was to make the device huge. And yet, here we have the Apple Watch and it has a full color touch sensitive display, all sorts of sensors, an entire computer architecture on a single chip, full Siri integration, and... Good battery life? It seems impossible, and since Apple didn't mention anything about that final, yet extremely important statistic, I'm worried they might not have fully pulled it off.

But then again, this is Apple.

As you probably all know, tomorrow is Apple's much anticipated September event.

Expectations

We're expecting to hear about a new iPhone (most likely two), as well as a pre-announcement of Apple's long awaited entrance into the wearables market (rumors indicate an "iWatch"). The event is being held at the Flint Center for the Performing Arts in Cupertino, a far bigger location which Apple has only used a few times in the past, and onto which Apple has built a strange white structure. Along with the usual reporters, we've heard Apple has invited top editors and bloggers from the fashion world as well.

The main rumors regarding the iPhone lead us to expect two new screen sizes, a 4.7 inch and a 5.5 inch. Along with the usual improvements to processor, camera, etc, there's also been buzz about the new iPhones including NFC capabilities. This would allow customers to use their iPhone as a mobile wallet, paying for items in supporting stores with a simple scan of their finger from Touch ID. Apple has supposedly already cooked up deals with CVS and Walgreens to support their payment system out of the gate.

Wishes

Expected rumors aside, here's just a few things I'm hoping to see in tomorrow's keynote:

• A camera which works better at night

The camera on my 5S is fantastic during daylight hours, but as soon as it gets dark out it is rendered nearly useless. I would love to see some improvements in image quality when shooting in darker environments.

• An increase in minimum memory

16 gigabytes of memory is simply too small for the amount of information people wish to keep on their devices these days. Apps, music, photos, and the notoriously evasive "Other" render 16 GB devices full in a ridiculously short amount of time. I'd love to see Apple shift the default configuration down and make 32 GB of memory the minimum.

• An increase in RAM

I'm tired of reloading every tab I have open in Safari after simply switching to another app. iPhones and iPads now pack a huge amount of power with their 64 bit architectures and A7 chips. It's time Apple gave them more RAM so they can better utilize this power, as well as to make day to day activities require fewer app/tab reloads and improve everyone's iOS experiences.

All in all, this is going to be a massive event, both in content and importance. I'll be watching it from my Apple TV, and tweeting comments here. I'll also probably cover some of the announcements on this website at some point tomorrow after the event, so watch for that as well. If you want to tune in live yourself, and don't have an Apple TV, you can do so on Apple's stream. The event kicks off at 10 AM PDT. If you're not sure when that is (time zones are a pain), you can check the live stream page for a live countdown and calculate what time it starts for your own time zone.

Exciting times for Apple fans.

After Acquiring it earlier this year, Apple has finally rolled out its new beta testing app, TestFlight. Free on the App Store, TestFlight will massively simplify the process of beta testing on iOS.

Before TestFlight, beta testing iOS apps has been a mess for developers and testers alike. Devs are allowed to seed their betas to a maximum of 100 devices. That's right, not 100 people, 100 devices. This means that if you have a universal app and your testers are installing it on both an iPhone and an iPad, each tester is now taking two of your already very limited testing spots.

On a beta tester's end the process is complex as well. First you must make an account with the developer's chosen beta testing service, then you have to register each of your devices with the service (which requires you to install a "provisioning profile" on each device). With profiles installed you communicate to the developer seeding you a beta what your registered email address is and which devices you will be using for testing, then the dev has to manually add your devices so you get the next seed. Any mistake with any of these steps and you don't get access to the beta for at least until the next update is seeded.

The situation is greatly exacerbated each year when fall rolls around and many testers purchase new iPhones and iPads. Devices are registered through their UUIDs, and since new devices have new UUIDs, they need to be re-registered and developers have to re-add them and remove the old devices. I've never seeded an app myself so I'm unsure exactly how this works, but I've been told by various devs that it's no where near as easy as deleting the old device and adding the new one; there are many more steps involved.

TestFlight Should Solve All of These Problems

Obviously TestFlight is brand new and completely untested, so it could end up creating just as many new problems as old ones it solves. That said, the promise of TestFlight is to simplify the beta testing process. With TestFlight, provisioning profiles will no longer be necessary. Instead, everything will go right through the official TestFlight app and can be installed to a tester's devices without needing to go through a third party service. Furthermore, and perhaps most importantly, betas are tied to each tester's Apple ID instead of their device's UUIDs. Thus, testers can install a beta their Apple ID has been granted access to on up to ten devices at their own discretion. The developer no longer needs to manually add each individual device, nor does each device count against the dev's maximum seed limit. Speaking of which, that limit has been increased from 100 devices to 1,000 Apple IDs.

As I noted earlier, this is a new system and there could still be a lot of issues (for starters, I have no idea how hard it is for devs to get their apps onto the new TestFlight in the first place), but the potential implications are massive and great news for developers and beta testers alike. I can't wait to get my hands on a TestFlight beta and really see how much better the experience is.

Great idea by IKEA, hilarious ad.

Yesterday I posted on a workflow I built in Editorial which pops up a user interface for connecting to a web server over FTP. That alone is quite useful to me for manipulating files already on the server, but before uploading new posts I first need to do quite a lot of work on them to get them ready to display properly on Unapologetic.

Last year I challenged myself to leave Squarespace behind and write a new website from scratch (▼)(▲)I have nothing against Squarespace, in fact I'm a huge proponent of the service. I just wanted to do some things on my website which were not possible within the boundaries of a template based system.. After a few months of work, Unapologetic was born. Fully coding the site had the advantages of letting me add some of my favorite touches, such as the in-text footnotes and drop down share sheets, but I lost the huge convenience of Squarespace's CMS.

Without a CMS and with my self-written code, before posting anything to Unapologetic I have to follow these steps:

• Convert markdown to HTML.
• Properly format every footnote with the necessary code.
• Add the share sheet code to the top of the file, which requires the new post's URL slug to be pasted into multiple different places within it.
• Place specific class tags on images depending on whether they are double portrait images or single landscape images.
• Duplicate the file and prepare one with the header and footer code for a permalink page and the other to be placed into the home page.
• Update the RSS file with the new post's information and a short description of it.

Doing that manually is a massive pain, and very much prone to human error. As such, I wrote a script in Pythonista last year which automated the whole process. I send it a file typed in markdown which includes the title, article type, and article description on the first three lines. The script breaks the file apart, takes out the top three lines and uses them to build the URL slug, identify the article type, and save the short description for the RSS update. Next it formats any footnotes with my custom footnote code, converts the text from markdown to HTML, formats images, adds in the code for share sheets (with the URL slug inserted in the necessary positions), then creates and uploads two different files, one formatted for the home page and the other for the permalink page. Finally the actual homepage and the RSS page are updated to include the new post.

I have been using this script for nearly nine months now and it works quite well, but after uploading my files there has been no easy way to edit them or otherwise manipulate them on the server. To solve the latter problem I built my FTP client UI, and for the former (as well as for the overall simplification of my posting workflow) I built another UI called "Post to Unapologetic".

This UI moves the process of posting to my website into a GUI, where it is far easier for me to check that I'm not making errors with the positions of the data on the first few lines. I can also tweak the article type, change the auto-created permalink if I want to, and write the description of the post last instead of first. For the most part this is just a graphical interpretation of the same script I've been using, but I've also made a few tweaks to really make it possible to use Editorial as a nearly full CMS for Unapologetic.

Each time I tap the "Post to Unapologetic" button on the UI, before changing the markdown to HTML, the script first saves another file, "md.txt", in the same folder as the new post which contains a dictionary of the post's data, including the markdown version of the text. With this file, each time I need to update a post on Unapologetic, either with new information or just to fix a typo, I open the folder with my FTP client and use a special button (▼)(▲)This button is only in my own personal version of the client so you won't see it if you installed the workflow yourself. to open and interpret the md.txt file. It opens in Editorial with the contents of the markdown version of my post, with the relevant data such as the post's permalink, description, article type, and title in the first few lines at the top. From here I can edit my post normally and then run my Post to Unapologetic workflow once again. The workflow reads the lines placed at the top and determines that this is an update instead of a new post, then it formats the post back into its proper HTML form, including footnotes, share sheet, etc, and overwrites the old file for the permalink and home page. Since it knows the post is an update, it skips adding it into the RSS feed or home page for a second time.

With this combination of two UI workflows, I've taken a shaky, text based method for posting which had no good way to make updates or error check before uploading files live to my website, and turned it into a much more stable and easy to work with process. Editorial's UI module has allowed me to build a content management system from scratch, and this CMS runs right on top of the app which I do all of my actual writing on.

I won't post the workflow publicly because it's completely customized to this website, and thus won't be useful to anyone else in its current form. If you are interested in putting something similar together for your own website though, and wish to see my code, ping me and I'll send you a link to the private workflow.

The things that iPads can do these days continue to amaze me. With the impending release of iOS 8, which brings with it Extensions and other fantastic new enhancements, I can't wait to see want the next era of iOS automation is going to look like, and look forward to my iPad gaining even more powerful abilities.

Today marks the much anticipated launch of Relay FM, the new podcast network from Myke Hurley and Stephen Hackett. I've been missing the voices of some of my favorite podcasters, and can't wait to hear the new stuff they've been preparing.

If you listen to your podcasts in Overcast, I made a nice little LCP action to automate subscribing to your choice of Relay podcasts (hat tip to Eric Pramono). It will loop through offering to subscribe you to each podcast. If you don't want to subscribe to one, just tap cancel and it will continue to the next one.

Direct Import Link for Relay Subscriptions action.

My podcast repertoire has been missing some key players the last several weeks, and I'm very excited to have them back.

It's a little late coming down the pipe, but today the update to my LCP guide finally landed on MacStories. Now with over 26,000 words (▼)(▲)Up from 18,000 previously, although much of that original text was also cut due to changes in LCP 2.3 and 2.3.1. the guide is packed with new content.

2.3 and 2.3.1 make building advanced actions in Launch Center Pro massively simpler and easier (as well as adding many more awesome new features), so if you've ever been interested in the app and were put off by the complexity of the actions, you might try checking it out again and taking a look at my updated guide for help learning the ins and outs.

You can find the guide on MacStories.

Today marks the release of Launch Center Pro 2.3, a huge update to one of my favorite apps. This update is not a big visual change like LCP 2.0 was, but instead focuses on making significant improvements under the hood and adding new features. With 2.3, Contrast has revamped the LCP URL handler, making huge leaps in stability and usability with nested input tags, a new list builder tool, and an encoding helper overhaul. Tacking on powerful new features such as IFTTT and Giphy integration, the [action] and [contact] tags, direct links to Dropbox files, location triggers and the awesome new LC Callback actions, Launch Center Pro 2.3 marks another new chapter in iOS automation.

I had a few thousand words written on the update and almost ready to post for this article, but seeing Eric Pramono's post on this subject, he seems to have already taken care of that for me. I'll save my words for the update to my Launch a Center Pro guide on MacStories, which you should look for some time next week.

In the mean time, if you're curious about the new features available in LCP 2.3, check out Eric's post (linked above) as well as Federico Viticci's post on MacStories.

I meant to post this shortly after my article on App Links last week but college finals distracted me, so here it is now.

I've seen some people suggesting that the adoption of App Links could lead to x-callback-url fading into obsolescence. This is a completely unfounded notion. Even though App Links and x-callback-url are both URL scheme-based methods of providing deeper and more powerful inter-app communication, they generally will not compete because x-callback-url provide's only a subset of App Links' functionality. It's true that the referer_app_link property of the App Links protocol provides a functionality practically identical to that provided by x-callback-url, but that functionality is bound by the rigidity of the rest of the protocol while x-callback-url is completely free from such constraints. In order for App Links to become some sort of standard for navigation, they have to strictly define the parameters possible for the first action that tapping an App Link will launch. This first action must draw data from an actual source on the web, and it must find a very specific set of instructions in that data. x-callback-url, on the other hand, has absolutely no restrictions on the first action which its x-success parameter is tied to. This distinction makes x-callback-url more versatile, but without the strict guidelines for finding information from the web to use in the first action, it could never do what App Links does on its own. App Links, on the other hand, could never be used for such a wide variety of actions for iOS automation like x-callback-url can be used for, because the referer_app_link property can only be used to return from navigating to some other place, and can only be defined once for each page of the navigating app. There is no way to use different referer_app_links depending on what link is tapped, so the secondary action is not limitless like x-callback-url actions are.

There are a few exceptions in which x-callback-url is being used in place of App Links, most notably in Google’s suite of apps. When you tap a YouTube link in Chrome, or vice versa, you will jump to the other app with a special back button to return you to the original one when you’re finished. Google can only do this, however, because they control all of the apps that the feature works with, and it is a fairly small list of apps. They basically built their own version of App Links, but it could never be used as an overarching protocol like App Links because Google’s developers had to manually build support for each app it works for into all the other apps. Greg Pierce, the creator of x-callback-url, has implemented similar inter-app communication between some of his apps, but again this can only be done because he built all the apps and has full control of all the code. App Links will work for any app without developers having to manually add support for each and every App Link-able app into their own code, that’s the entire point of the protocol.

These general distinctions are what have led x-callback-url to be used mainly to increase productivity by tying together powerful and usually user-customized actions. App Links, on the other hand, will remain geared simply towards improving navigation, and will never become nearly as great a productivity tool as x-callback-url. Thus, while in some cases they may get in each other's way, for the most part these two protocols will live in harmony, neither eliminating the other.

At its f8 developer conference earlier this week, Facebook announced App Links, a new open source protocol to allow developers to deep-link to mobile apps from web browser environments. From the App Links website:

Right now, linking on mobile is a lot more frustrating and complicated than it is on the web. There isn’t an easy, consistent way to control what happens when someone clicks on your content in mobile, which makes it difficult to provide the best experience for your users. It’s also hard to find out when—and how—to send people out of your app and directly into another.

We built App Links to help with that. It’s an open, cross-platform solution for app-to-app linking that gives you the tools you need to expose deep links in your app or to link out to others.

The idea of deep-linking to apps arises from the fact that many native apps have significantly better experiences than their web versions when being viewed on the smaller screens of mobile devices. Take Dropbox for instance. The Dropbox mobile app provides an excellent experience for viewing Dropbox content on iPhones or iPads. Accessing your Dropbox files on the web through Safari or another web browser is possible, but it is nowhere near as polished of an experience. The issue here is that anytime you tap a Dropbox link on your device, it is not smart enough to do anything except launch the Dropbox website in the nearest web browser. Even though you have a perfectly good Dropbox mobile app ready to give you exactly what you want in an environment built for your specific device, you're forced to use the lesser experience of the web view.

App Links is an attempt to fix this problem. If you tap a Dropbox link in an app that supports App Links, it will figure out that you have the Dropbox app installed on your device and redesign the link as a Dropbox.app link instead of a Dropbox.com link. Then when it opens the link you will launch into the Dropbox app to view the content in question instead of seeing it in a web browser. This is known as "deep linking" because that content is "deep" inside of the Dropbox app. (Really it's all on the web, because that's where the Dropbox app gets its data, but the point is that this content is not accessible through the top level hierarchy of the Dropbox app. It's not easily found unless you search "deep" inside of the app, so linking to that content is "deep linking".)

This idea may seem foreign, but we actually deal with it every day on the web. Basically every URL is a "deep link" to some sort of content on the web. Every article that you follow a URL to get to was buried somewhere deep in that website's hierarchy, but that URL was able to link you directly to it. This is an extremely powerful concept which has been so mastered on the open web that we don't even refer to it as deep linking there, it's just linking. In the mobile app ecosystem, however, deep links are still struggling to find mainstream support from developers. We take it completely for granted that every single piece of content on the web is accessible from a link, but in most mobile apps, content is only accessible by navigating your way through the app's hierarchy until you get to the location of the content you're searching for. Imagine if every time you wanted to go to an article on a webpage you had to go to the website's home page, navigate to the section the article is in, then scroll through other articles until you found it. The notion of navigating websites in that manner, without direct, deep-link URLs, is ridiculous.

The problem with native apps, the main reason why deep links did not become as ubiquitous as they are on the web, is that unlike websites, apps are not always accessible. A native app link can only work if the app it corresponds to is installed on the device, and most developers cannot be very certain that their app will be installed on any given device. (▼)(▲)A notable exception to this rule is Facebook. If you take any given iOS device, the likelihood that the Facebook app is installed on it is probably higher than almost any other app besides Apple's own. App Links seeks to solve this by creating an open source protocol which developers can implement to identify whether an app is installed, then change web links so that they will launch into the corresponding apps instead of the standard web views. These won't just be basic app launching URLs, but true deep links to send you to the exact content you want to see, just in an app instead of a web view. Tap a Facebook link and see the result in the Facebook app. Tap a Spotify link and start listening to the song in the Spotify app. Facebook has launched app links with quite a few big name supporters already, including the aforementioned Dropbox and Spotify as well as Hulu, Pinterest, GoodReads, Redfin, and several others. Of these, however, the only ones which will actually be implementing App Links at this time are Facebook, Mailbox (which is owned by Dropbox), Quip, and Spotify. The rest will simply be publishing App Link metadata (More on what that means later). In other words, while links in the apps from the full list of supporters will have the capability of being changed from web links to app links, only when you click those links from one of the four apps that have implemented App Links will they actually send you to the app instead of the web.

App Links are a great idea, inspired by real problems with iOS (▼)(▲)App Links support other major platforms too, but I'm focusing on the App Links implementation in iOS for this article., but there are a lot of concerns with this type of protocol as well. In this article I'll try to explain some of the problems, as well as the advantages, that may soon be associated with App Links. First though, you need to understand exactly how App Links work, and the difference between publishing App Link metadata and actually implementing the protocol.

How App Links Work

As I've written about before, basically the only way for apps to communicate on iOS is through URL schemes. (▼)(▲)There is also the "Open in..." menu, but that's mainly just for transferring documents between apps. These work just like website URLs do, providing a simple "domain name" which, when called, will launch you out of your current app and into the app associated with that name. These URLs follow the basic syntax of yourapp://, where "yourapp" is whatever title a developer has registered his or her app to. Developers have the option to register their apps to a URL scheme, but unlike with website domain names, they don't have to. Similar to website URLs though, developers can build their schemes deeper so that adding more data after the :// can direct users to places further within the app, or even launch actions inside of it. These schemes are the foundation on which App Links are built. Apps which support App Links will likely have complex URL schemes to allow "deep linking", creating specific links for every piece of content accessible through the app so that a particular URL action can launch users directly to a specific item of content "deep" within the app.

Two things have to be true for you to click a link and have it open in an app instead of a web view. First, the app you are clicking the link from has to have built in support for App Links, and second, the publisher of the link you are clicking has to have included App Link specific metadata in the HTML of that link's webpage. This is the distinction between being an App Link "publisher" and having actually implemented the App Links navigation protocol. This is also the biggest disadvantage App Links is going to face in gaining any traction. App Links can only work if you are clicking on a link which has App Link metadata and the app in which you are clicking said link has implemented the App Link navigation protocol.

So how exactly do publishers include App Link metadata? That part is extremely simple. Within the HTML <head> tags of each webpage, publishers must simply include a few extra lines of code which hold the data App Links needs to function. Each line of code will look something like this:

<meta property="al:DEVICE-TYPE:PROPERTY-TYPE" content="DATA" />

For each item, "DEVICE-TYPE" will either be ios, iphone, or ipad. "PROPERTY-TYPE" will then either be url, app_store_id, or app_name. Finally, "DATA" will be the piece of data associated with the property type. Within each line of metadata, publishers can choose to add code for any or all device types, depending on how many manifestations of their app there are. If the app is universal, they only need to provide metadata for the device type ios. If their app is iPhone or iPad only, they can choose for themselves whether they want to use ios anyway, or use iphone or ipad depending on which platform their app is on. If there are separate versions of their app for iPad and for iPhone, then they can include metadata for both the iphone and the ipad device types. As for properties, the url property will include the URL action to launch to the specific piece of content within the corresponding app. The url property is also the only required property, everything else is optional. Next, the app_store_id property will include, not surprisingly, the app's specific App Store identification number. Finally, the app_name property will include the name of the app. The last property that most content publishers will want to include is the al:web:url property. This is that actual web URL for the page, and in fact probably the same URL as the one the user clicked to get to the App Link metadata. There is also the option to include an al:web:should_fallback metadata line which can be set to false if there is no web version of your content, or in other words if you have only an app but not a website. This is possible because Facebook itself, as well as a company known as Parse, are providing services to publish App Link metadata without actually having any web content. In that case, a publisher could post a link which directs to a Facebook or Parse webpage which simply holds the metadata and nothing else. To the user, they would tap the link and open straight to the app without ever seeing that there was no web version.

So that's how publishers can start adding App Link metadata to their webpages. If the explanation may have seemed complicated, the actual implementation is really just a few lines of simple and repetitive code, which to anyone who knows how to write HTML will be extremely easy.

Simply having publishers include App Link metadata in their webpages isn't all that App Links requires. It also necessitates that the app in which an App Link is being clicked haas implemented the App Links navigation protocol. This protocol describes a few extra steps between a user tapping a URL and that URL being opened. First, a request for any metadata beginning with al wil be sent to the target URL. If any metadata is retrieved, meaning that webpage has published data for App Links, then the navigating app will next search through the returned metadata looking for device types of the same type that the current device is (i.e., if you're tapping a link on an iPhone it will search for any metadata beginning with al:iphone, but if you're tapping on an iPad it will search for al:ipad). If it doesn't find metadata for the device, it will search again for metadata containing al:ios. If that's not found either, it will check whether al:web:should_fallback has been set to false. If it has been, the navigation will fail and nothing will happen. If al:web:should_fallback has not been set to false, the URL will be opened regularly in a web view. However, if it does find any metadata either associated with the proper device type or containing al:ios, it will proceed to construct a new URL to launch instead of the one being tapped. This is a process as well. First, the navigating app will check whether the URL defined by the url property of the App Link metadata can be opened on iOS. Assuming the publisher did not have a typo in their URL action, the only reason this would fail is if the app is not installed on the device. If the URL does not fail, meaning the app is installed, it will launch the URL and send the user into the native iOS app corresponding to the link, and to the proper place within the app. However, if the URL does fail, hopefully meaning the app is just not installed, not that the published URL has an error, then the app_store_id property can be used to open the iOS App Store to the page for the uninstalled app in question.

Since all of this goes on in the background, to the user there are only a few possible outcomes if they tap a link which has some sort of App Link metadata in its markup:

• If the app is installed on the user's device, open the content from the link inside of the app.

• If the app is not installed on the user's device, open the App Store to the app's download page.

• If there is no App Link metadata associated with the user's platform (e.g., the publisher included App Link metadata for only the Android operating system but not iOS), open the URL regularly.

• If there is no App Link metadata associated with the user's platform and there is no web version of the content (e.g., the App Link is for an Android only app which does not have an accompanying web component), do nothing.

There are two other properties defined in the App Links navigation protocol, but rather than metadata properties defined in the link that is being navigated to, these properties are defined by the app doing the actual navigating. That is, the app from which a user is opening an App Link. The first of these properties is the al_applink_data property. This is a property which is sent as part of the URL action to the app being launched by an App Link, and it simply contains context for the navigation. That is, this property contains the target URL that was initially being navigated to before the App Link took over, the app token of the navigating app, the version number of the App Link protocol being used, and the identifying string for the library that the navigating code is using to navigate. Presumably, an app being launched by an App Link can choose to make use of this contextual information or just ignore it. In the future it will become significantly more useful when more version of the App Links navigation protocol exist. In that case, if an older app which has not been updated is the sender of the App Link, the receiver app can identify the fact that the sender is using an old version of the protocol and adjust accordingly.

The second property which the navigating app can send in the URL action is called referer_app_link, and this one is much more interesting than al_applink_data. referer_app_link provides a URL to return to the navigator app after the user is finished with the content they navigated to in the reciever app. The developer of the reciever app can choose to look out for the referer_app_link property and then implement a back button into their interface. That way when the user wants to return to the app from which they tapped the App Link, they can just tap the back button to automatically jump back to the app they had navigated from.

Advantages of App Links

With App Links, Facebook imagines, and is hoping to begin to create, a world in which low quality web versions of apps no longer need to be dealt with. Imagine if every time you tapped on a link to a tweet (even outside of Twitter apps) your device could open that tweet in the official Twitter app instead of the terrible Twitter web app. Not only would you be viewing the tweet in a better environment, but you would already be logged in and free to reply, retweet, favorite or any other action, which is often a huge pain to try to do in Twitter for the web on an iOS device. Not only that, but when you finish with the tweet, a button will be waiting for you to tap to go straight back to whatever app you had been in before. This would work the same way with any app, saving you time and annoyance by never again forcing you to use the web version of Dropbox, Spotify, Facebook itself and more.

This could be the first step to the inter-app communication that many of us nerds have been dreaming of since we saw the capabilities of x-callback-url. Best of all, average users, those who have little knowledge or interest in what's happening under the hood of their devices, could make use of these new capabilities without ever needing to "install an action" or change their habits in any way. They would simply get a better overall experience on their devices.

Difficulty Getting Adoption

By far the biggest hurdle that App Links will face is getting wide adoption. Unfortunately, the likelihood of App Links ever becoming a complete standard is fairly low, because it's highly doubtful that Apple would ever implement App Links, a third party protocol, into Mobile Safari. In other words, App Links will very likely never work in the most popular web browser available on iOS. This leaves it to try to scrape up the leftovers: web browsers built into third party apps such as Twitter or email clients (Mailbox has already committed to supporting App Links), as well as full-on third party web browsers like Chrome or iCab Mobile.

Without finding its way into Mobile Safari, App Links has a steep uphill path to reaching mainstream support. The only way I could see Apple ever implementing the protocol is if it manages to become a true standard among third party web browsing experiences and Mobile Safari is falling behind without it. Yet still, it seems more Apple-like to just build their own protocol into iOS than to implement one built by Facebook, particularly when you think about some of the possible issues that could arise from people abusing the App Links protocol.

Concerns With App Links

The reason Apple has not implemented powerful inter-app communication up until now is because it is a danger to security. By keeping every app in its own sandboxed environment, it's very difficult for apps to do something in the background without the user's knowledge. URL schemes are the only method of inter-app communication that is not fully controlled by Apple. That lack of control does mean that running URL actions is a security risk. Once you launch an action, it's likely impossible to stop it from fulfilling its function unless it is a long chain that bounces between different apps. With the current state of iOS automation, this has provided very little danger because the users are completely in charge of which action they install and run. Furthermore, it's a field predominantly populated by people who are more advanced users of iOS, and likely to realize if an action they've installed has done something other than what its description had said it would do.

Security issues related to URL schemes are in no way going to be some sort of malware. iOS is still sandboxed, and running a URL action can't install any malicious apps from outside the App Store or anything like that. URL actions can become dangerous, however, when they send you somewhere unexpected. As far as I can see from the information on the App Links protocol that Facebook has published, the protocol does not include any sort of check to make sure the App Link it is navigating to is actually going to the content it should be. Of course, there's really no way for the protocol to do something like this because it can't read the content it sends the user to, it can only launch the action defined in the metadata of the webpage it scrapes. Without a system of checks, I can think of a few different, and all seemingly easy ways in which the system could be abused to take advantage of unsuspecting users. (▼)(▲)I only know as much as what was written in the documentation, so it's possible that App Links does have some sort of built in features under the hood which would try to prevent the following situations. If you're aware of something like that, please contact me about it so I can update this post.

First, App Links could provide a way for advertisers to get more users to download their apps by paying websites to use app_store_id properties for the advertiser's app instead of their own. This way, if the URL provided by the App Link failed to launch, meaning the user did not have the app of the link's publisher installed, the fallback could send the user to the App Store to download an app which is not the app associated with the link, but rather some random game or another app which an advertiser has paid the App Link publisher to link to. Sure, the publisher might get less downloads of their app, but I can't imagine that advertisers won't be able to find a price that will convince some publishers to forsake a few downloads of their apps. Particularly when you recall that Mobile Safari will not work with the link, so the majority of users navigating to it will not be sent to the wrong place.

Next, just as the app_store_id property is not, nor likely could be checked by the App Link protocol, neither is the url property, nor the web:url property. Either of these could be tweaked to send the user to a different website than the link they actually tapped would have taken them to. Users could tap a link and unsuspectingly be redirected to porn or other explicit material on the web. They could even be directed to phishing websites. It's all the same problems that everyone who uses the web constantly faces, but now the links can be hidden another layer down and you may never actually tap the link you end up being directed to. Just like with the App Store links, all of this nefarious redirecting will cause the actual website of the link to lose hits because the user never reaches it, but advertisers or other organizations would surely pay them for their troubles.

The final concern I have with App Links is less tied to malicious uses of the protocol. Rather, it's simply the annoyance that will inevitably come from tapping a link and being redirected to the App Store download page for the website's app instead of seeing the content you were looking for. This is even worse than the infuriating tendency of many websites to throw popups on top of their content informing you that they have an app in the store, because now they can actually throw you out of your app instead of just asking with a popup.

Conclusion

All things considered, App Links seem to be more trouble than they're worth. I like the idea of the future that Facebook is pushing for, but with rumors of better inter-app communication coming in iOS 8 or 8.1, I can only hope that Apple reveals a way to do this without the shortcomings of Facebook's implementation. Even if they don't, I might actually prefer having to use lower quality web versions of native apps sometimes as long as they promptly and predictably get me to the information I want. With App Links, each link could do one of three or four different things, and the inconsistency with that makes me shy away from fully supporting the idea. At least with standard links there are no surprises: you tap the link, it opens in a web browser.

That said, Facebook is definitely pushing in a direction that I want to see iOS go. If there were a more foolproof way for links to know to open apps instead of web views, I would support it completely. The idea of always being able to use the higher quality native app experiences of internet content is an amazing one. I just don't think we're ready for that yet, and when we are it may need to come as a first party API, not a third party protocol.

I'm happy to have had the opportunity to write for the beautiful new redesign of MacStories 4.0. Similar to my previous article for MacStories, Automating iOS: A Comprehensive Guide to URL Schemes and Drafts Actions, this new one is an exhaustive guide for another Titan in the field of iOS automation: Launch Center Pro. Whether you're a complete beginner, or an expert on the app, my guide will bring you up to speed on Launch Center Pro's full feature set, including tips and tricks to access LCP's most advanced capabilities.

You can check out the guide on MacStories.