Everything that went wrong while building the Tumblr iOS share extension | Hacker News Reader

Everything that went wrong while building the Tumblr iOS share extension

bryan.io

A culprit of Apple's insistence on a combined completion date for just about everything. Xcode has similar oddities. Sometimes it feels like today's the date, it compiles, ship it. We used to call that Microsoft Beta.

This is compounded by the fact that you can't publicly discuss issues with prerelease versions of iOS/Xcode (although they seem to be relaxing this as of iOS 8, there are still restrictions). This prevents excellent blog posts like this from helping a wide audience of developers when they need it most (trying to update their app in time for release).

That's what the Apple Dev Forums are for: http://devforums.apple.com

Absolutely, the forums are very useful particularly at beta time. But they aren't the best or only way to share information. I think Apple could still open up things a bit more here to help developers without harming themselves. There are no real secrets once millions of developers have the betas anyway.

I'd love to see them open up more around bug reports too, there's a lot of mystery and guesswork due to the closed nature of Radar. (Not to mention all the duplicated effort in Open Radar that tries to compensate.)

I love articles like this. Everyone's quick to brag about the things that go right, but too few tell about the difficulties they encountered along the way. In the long run, warning others about upcoming speedbumps is at least as important.

This is a really useful writeup. Might consider doing one on trying to convert my app to use WKWebView ( hint. lots of radars )

I'm curious how the Android share intent compares - it's been around a lot longer.

Navigating on Android is vastly different -- it's designed so every activity (screen) is uniquely identifiable and can be referenced by other apps, browser URLs, etc. Activities can register which intents they support in AndroidManifest.xml, so it's not dynamic, but not heavy-weight either.

Sharing from a third-party or launching from inside your own app, it's largely the same thing to an activity. As you navigate, it's like a web browser, your back button keeps a history of where you've been across apps that will work different than controls within the app to navigate back (Up). You can also pass content between activities, just as you would for sharing or viewing actions.

Primarily, navigation to different activities is via Intents: http://developer.android.com/guide/components/intents-filter... You can explicitly tell it which activity to load (as if using URLs) or you can identify the action (view or share) and mime/type of your text or binary data. http://developer.android.com/training/sharing/send.html

Common intents: http://developer.android.com/guide/components/intents-common...

So "sharing" or interacting between apps, or within your own app, or your app and system apps, is... basically baked in to Android, and far more common than you'd expect. It's like a more powerful version of "Open With" that isn't restricted to files saved to disk.

I'm not sure you can send more than one type of data at a time, though it wouldn't surprise me if there's an Intent/Action for that as well.

The counter to this is incredibly long lists of apps to pick from, prompts for which app to view something in (like a URL or media type) and other annoyances that you get with increased flexibility. It's pretty cool though. You can even have certain URLs open certain apps as you browse in Chrome, so if your Google search takes you to a blog that links you to Netflix, you could hop directly from the Google app, to the Chrome app, to the Netflix app and it could feel seamless, one screen to the next.

sadly this great idea is implemented like crap even in goggles own apps.

open email, click a link which open in the browser, click a link which open in YouTube. now you have the email app activity in your recent app list, but if you switch to it you get a you tube video. now you either have the video/web page/etc, or the email message. not both. to get back to your email you have to press back all the way... it rarely creates such a clumsy situation, but every time it happens you're guaranteed to get very close to smashing the phone on the wall.

You eventually get used to it, I think of opening each app from intents like a stack and you press back to 'pop' the apps off the stack to get back to email (in your example).

Yep. And similar to seeing tabs in the switcher in L Preview, I expect we'll see a richer "switcher" that's more activity or history aware in some future release...

One thing that is different is that there is no "shared container" - data is serialized to the Intent bundle (an IPC mechanism that basically is just a bag of stuff), and the context that you receive the data in, is your app (with your file permissions, security keys, etc), not a tertiary one.

Yep. Effectively, your app can't easily communicate back and forth with a third-party app using stock Android code. And there's little support for "embedding" other apps into yours, just context switching and data sharing between screens. So that's new here. Android really was designed around these full screen "activities", and created "fragments" only for use by first-party applications, or included as libraries from third-parties. The idea of running someone's app within your own... that's not supported. Heck, even Chrome doesn't have extensions. For an open platform, Android does have its limitations... ;-)

That's not really true. If an app wants to be able to constantly communicate with other apps it can pretty easily launch a background Service which can be bound from other activities.

Yes, third-party devs have flexibility in defining how apps can cross-communicate. But in Apple's case, they're doing it for us. Kind of like how Google tried to nail accounts and sync for Android. I write for both platforms FYI, so while I may not get the details 100%, and leave things out, I'm pretty happy with both platforms overall, just for different reasons for each.

Nice deep dive into an area I'm not familiar with. If you're writing an extension for ios8, this seems like the right post to start with.

Thanks! It's linked to in the post, but we've also created a GitHub repo containing all of the same information: https://github.com/tumblr/ios-extension-issues.

Seems like a better way to solicit feedback and provide updates than a blog post.

I've been building an app with a Today extension, it has been...interesting. The view auto layout parts aren't quite working correctly, testing is a bit of a mare in the Simulator and deployment testing is also a bit of a pain. It has loads of potential, but it's definitely still got dev beware areas.

Missing from this list: the iOS share dialog is insanely slow.

This sounds like a nightmare. Share invocation is built in to BlackBerry 10 and much simpler. Fairly certain none of the issues outlined here exist. At least Apple added it though.

Reply on news.ycombinator.com