ShareKit
Overview
ShareKit is an open source framework that can be dropped into any iPhone or iPad app to instantly add full sharing capabilities.How It Works
Integration is super easy. A developer can take a url, image, piece of text, or file and just say “hey ShareKit, share this”. ShareKit will present the user with a list of services that support the content they are sharing, handle logging them into the service, prompt for any additional information such as a caption, and display an activity indicator while uploading. ShareKit makes it easy to access individual services as well. A developer can simply write something like: [SHKTwitter shareURL:@”http://getsharekit.com”]; ShareKit will shorten the URL, present a dialog to let a user write a message, and even hold onto to the message to send later if the user is offline.Features
The initial version of ShareKit already has support for Delicious, Email, Facebook, Google Reader, Pinboard, Read It Later, and Twitter. It supports four types of content: links, images, text, and files. ShareKit even works offline. Users can share items without an internet connection. ShareKit will hold onto the items until a connection is available. The UI is also completely customizable. It is very easy to make ShareKit match the look of your existing application.Developer Benefit
For developers, adding sharing features to an app is a source of dread. It takes a LOT of work for each service that you add. You have to learn each service’s API, probably learn OAuth, design and build UI to handle all the interactions of logging in and collecting information, and write code to make requests and handle all possible errors. You have to do this for every service and every service has a unique API. It makes it very difficult to add all of the services your users request. In the iOS SDK we have access to MFMailComposeViewController. This is an Apple provided view that lets apps present an email dialog to the user. You feed it some starting values like a subject line and body content and it pops over your existing application, lets the user do their thing and goes away when they are done. This is what I wanted in my apps. I wanted the same controller but for Twitter, Delicious, Evernote, and everything else. That’s what ShareKit is.User Benefit
As it exists today, the user experience for sharing is incredibly inconsistent across all apps. Because of the work that goes into adding each service, the services supported in an app are entirely dependent on what the developer has time to implement. Ideally a user should be able to use any app they want and be able to share with all of the services they use. By making sharing features a trivial development step, I’m hoping that we can see movement in a direction where we don’t have to pick our apps based on what services they support.Additional Services and Further Development
ShareKit is completely open source and anyone can contribute patches or additional sharing services. Modules for Evernote, Flickr, and Dropbox are already underway. When new services are added, they can simply be dropped into any existing ShareKit project. If you are a developer and would like to help contribute to ShareKit, a good place to start is the list of issues and feature requests.Apple Accepting iPad Apps Before We Have iPads
Of all the possible scenarios we (developers) considered for exactly how Apple planned to roll out iPad apps with the release of the iPad, this was the one I dreaded the most.
Apple is now accepting iPad applications to the review process. If you submit before March 27th, you may be included in the grand opening of the iPad App Store.
The only problem? No one has an iPad yet and won’t until April 3rd.
Anyone who has developed on the iPhone SDK knows that how an app runs on the SDK simulator can be night/day vs how it runs on the actual device. Even if it runs flawlessly on the simulator, I’ve never had an instance where the first time I ran a new app on the device it worked to my liking. There are bugs and crashes that didn’t occur on the simulator, there are slowdowns in areas that you thought were fast, and usability changes you didn’t expect.
So we are now faced with a risky decision: go for fame and fortune, submit an app and cross your fingers that it actually works or wait, miss the hoopla, and submit something you KNOW works.
iNeedAShorterName
I really wish someone (probably Apple) would standardize a way to describe iPhone/iPod Touch/iPad apps in one word. When you talk about apps for other devices you simply say: it’s an Android app, Blackberry app, Mac or Windows app. You do not have to specifically list all of the devices that the application works on. You could simply say ‘iPhone (OS) app’, but because this language is specific to a device, it can easily lead to confusion. The last thing a developer wants is for an iPad user to see there is an iPhone app available and not make the connection they can purchase it for their iPad. This arguably was less of an issue between the very similar iPhone and iPod Touch, but once the iPad drops into a whole new market, this will be even more confusing for the end user. This is why you see a lot of the lengthy ‘iPhone/iPod Touch/iPad’ strings when describing an iPhone OS app.
When trying to design a clean and concise layout, it’s simply too wordy, too ugly. For example, on Read It Later’s home page, I have links to all of the platforms that RIL is available on. You’ll see I have ‘Add to iPhone/iPod’. I’m not looking forward to squeezing in ‘iPad’. Same problem with the main navigation at the top where I list the major platforms: ‘Firefox, iPhone, Mobile, All Browsers’. When designing that I gave up on including iPod, but now that the iPad is imminent, I feel like it will need to be squeezed in there as well.
The iPad: It wasn’t created for us.
I’ve had some time to think about today’s release from Apple, the iPad. I’m finding that the more I think about it, the more disappointed I am. But I know why: The iPad was not created for us (and by us I mean the tech crowd).
Take a look at today’s release. Remove all of the changes to the software and the new iWork/iBook products. If you look solely at the hardware and the device itself, there is nothing revolutionary here. There are no revolutionary new input methods, no new integrated additions (like the compass was to the 3GS and the camera to the Nano) and nothing new in form factor (aside from size).
Now look at the software. While the default apps like Mail, Safari, Photos, and Calendar got a refresh, the OS itself is fundamentally the same. The home screen simply has more space in-between the icons and a background image. In fact, even though you have a bigger screen, you still have the same number of icons per page. There is no multitasking, no OS-wide gestures, and no major APIs opened to developers.
The problem is the tech community expected to see iPhone OS 4.0 today. We expected to see something we hadn’t seen before.
All Apple did today was release the same product they already have, only bigger.
And you know what? It’s going to work.
The iPad is targeted towards all of the users who simply need a device to browse the web, check email, watch videos, go on Facebook, and play a little Farmville. And as Apple knows, this market segment is a LOT bigger than the ‘I need multi-tasking and Minority Report style input’ crowd. I bet that for the majority of people in Yerba Buena Center today, the iPad will not be their mainstay machine. Most of them will buy it, play with it, or develop on it, but most of our computing will be done on laptops and desktops.
The iPhone and iPod Touch have been incredibly successful. If Apple released a new device today that required a steep learning curve with revolutionary input controls and a new OS unlike anything we’ve seen before, your mother would not care. Your non-tech-savvy friends would not use it. What Apple is doing is simply taking something that works very well and making it reach a little farther.
So what I’m really disappointed about is how much I got sucked into the hype cycle this round. I’m actually really excited to read, watch, play, and develop on this device. The iPad is a going to be a great device, it’s just not the technological savior we were looking for. Still, as I look back at all of the really amazing things we all hoped the iPad would be, I realize that these ideas are now out there. It may or may not come from Apple, but now it’s just a matter of time.
In Defense of the App Store Review Process
Trust me, I know how badly the App Store’s review process can burn you (*Ahem*). In fact, while I’m on the verge of trying to push out Read It Later 2.0 as the busier holiday season approaches, I’m expecting even more frustration. Since Joe Hewitt quit the iPhone platform, a strong discussion has emerged and a lot of good ideas have been surfaced. However, one bad idea that both Apple and I know will never happen is: ditching the review process all together. Over the last few weeks, people have talked a lot about how the review process is bad for the open web. What I think is interesting about this concept is that the one company I believe is probably the most open of all, Mozilla, has a review process for extensions. All of those free, open extensions you have in your browser? Those go through a far more rigorous review process, have their actual source code looked over, and sit in a line generally longer than the one at Apple. Yet, even though this has been happening for years, I would bet no one has heard of any controversies there. I know this because of my time building add-ons but also because around the time of Firefox’s 3.0 release, I was an AMO Editor (extension reviewer). (Technically, I still am, but have simply not had the time to volunteer recently.) The review process is absolutely necessary. Mozilla’s reviews stop a LOT of junk from getting through to the end user. When you browse the AMO directory, you can be assured that every add-on in there is useful to some purpose and more importantly, it’s safe. It’s not going to steal personal data, it’s not going to install additional programs or do anything not clearly described in the description. Mozilla’s process, though longer and more in depth, differs from Apple’s in only a few ways. Yet, these make all the difference between controversy and satisfied silence.
1. Experimental Add-ons
Anyone can submit an add-on to AMO (Mozilla’s add-on directory), it will appear immediately and be available for download. However, this add-on is flagged as ‘experimental’ and when the user views/tries to install it, it warns them of the potential consequences of using untested software. After the add-on has been submitted it can be nominated for public status. There are a number of criteria your add-on must meet in order to be considered. Overall your add-on has to be useful to a wide portion of users, well tested, and has been received favorably from those who have tried the experimental version. Once it’s been nominated, it enters the review queue for an AMO editor to look over and eventually reject/approve it. This means that anyone can get into the directory immediately and start having people try their add-on. Once it’s flushed out further, they can push it through to the more public, much more lucrative (download wise) public side. If it’s an add-on that is only useful to a small number of users, it will stay as experimental and won’t clutter up the main AMO directory.2. Responsiveness
If you send an email to the AMO editors, you can almost always expect a response within a day. I am still on the email list for the editors address and from time to time check in, but I always see the editors responding quickly and generally with helpful information to answer the developers question. Often there is thoughtful conversation between the editors trying to determine the proper response before replying. This is the most important factor in a successful review system. A developer should be able to get any and all questions answered in satisfactory way as quickly as possible. In the way that Apple works, it’s generally pretty difficult to illicit much response from their blackbox. In the past year I’ve sent several emails over to Apple’s side and was often met with silence or in one case a month long delay before a response. This is unacceptable. I will say however, the most recent email I sent to the review team was replied to within 17 minutes. Though the response was short/vague it may mean things have certainly improved since earlier this year.3. Quick Modifications to Rejections
When an add-on is rejected, you receive an email with the reason why and the name of the reviewer. Generally, if the reason for rejection was something that can be fixed relatively quickly, you can email that reviewer back, say you resubmitted the fix and they’ll take another look at it. You won’t have to restart the lengthy wait to be reviewed for something that took you 10 minutes to correct. This is one of the loudest complaints you’ll hear from iPhone developers. If you wait in line for 2 weeks and then ultimately get rejected for something as minor as an icon, it’s incredibly frustrating to have to start all the way back at the beginning of the queue. The 2 week long wait will seem a lot less unbearable if you know you can still get approved given a minor oversight (or problem with policy).…
Mozilla’s system is far from perfect. It also suffers from one of Apple’s biggest problem in that updates to existing add-ons can take a while to get through the queue. However, the responsiveness offered by AMO’s team, means that if you are rejected for something arguable or minor, that you can still get through just after a few emails and a few changes to your code. Apple’s current process is running on ground that cannot stand for much longer. The number of apps is growing rapidly, and unless they hire hundreds of reviewers, it’s unlikely that all of these applications are getting thorough testing. From what we, as developers, have seen is that the review generally lasts a minute or two. From stat tracking to server logs, a lot of developers can see that the reviewer doesn’t even use all of the functions within the app. If this is the case, then the usefulness/stability of the apps appearing in the store are a lot less credible. They have over 100,000 apps in the store, but let’s be honest, a huge number of those are crap. It would be far more useful to the end user to have an app store that had less apps, but higher quality than vice versa. By implementing some sort of intermediary (like Mozilla’s experimental stage), they could offer developers a place to stand on their platform while being able to dedicate more time to those in the main app review process. More time means, better reviews, more responsiveness, and less of a wait time. The App Store review process certainly could use some improvement, but we need to accept that it’s there for good and push harder for smarter changes to improve the review process, rather than waste our time trying to abolish it.Try It Button in the App Store
In the app store, it is very common to find that paid apps have an accompanying free or lite version. It’s a great way to let users get a taste of an application or game without having to blindly purchase it.
It’s so common that often when I’m browsing through the store and I find a game or an application that looks interesting, I’ll open up the search tab and look to see if they have a free version to try first. This has saved me from spending money on some terrible games but also has lead me to purchase a ton of games that I got hooked on using the free version.
Since this has now become almost a standard for a lot of applications, I think the App Store can do a better job at bundling these free and paid versions together. I’d like to skip the extra steps involved in having to seek out free versions whenever I find a cool app while browsing the store (especially in the new Genius section).
If developers were able to link free and paid versions together through iTunes Connect, Apple could then display a small shortcut on the paid version that lets users know there is a free version out there to try. Even a small ‘Try It’ button underneath the purchase/price button would save a lot of hassle.
It would benefit users by allowing them an easier way to try out applications before dropping money on them. It would benefit developers by giving them one more chance at hooking a customer who might have otherwise balked at the price at first.
One Touch Rotation Lock on the iPhone
One feature I get a lot of comments about in Read It Later Pro is the one touch rotation lock. When the user rotates their phone, it displays a lock icon for a brief second. If the user taps the lock, they can lock the rotation of the device so the view does not change. This is so much easier/faster than making a user go back out to the options screen and setting a toggle.
Since a lot of users have said they wished other applications had this feature I thought I’d release the source code so that other developers could easily add it if they wish.
How to Use
Every app is going to be unique, so depending on how your application and it’s views are designed, this may or not be a quick drop-in. I would start first by downloading and viewing the example project. There are two parts you would need to integrate into your application.1. Add the view controller additions to your UIViewController
Open OneTouchRotationViewController.h and OneTouchRotationViewController.m. You will see the additional properties and functions I’ve added to the UIViewController. In most cases, you can simply copy and paste them into your main view controller. The example project has no extraneous methods or code, so you should carry over almost all of the code from the two files into your own. Make sure you get:- The definitions in the header (.h) file.
- The #defined degreesToRadians function at the top of the .m file
- The OneTouchRotation enum
- The synthesized properties line
- The hideLockAfterNumberOfSeconds constant
- All of the source for the rotation functions listed in the .m file
2. Add the rotation notification
Where you put this may again depend on your application. If you open OneTouchRotationAppDelegate.m, you’ll see that I add it right when the application starts up. This event tells your view controller when the device has been rotated.3. Add the icon images
I provided the same icons I use in my own app. Feel free to modify them if you wish. You’ll want to add these to your own project by dragging both rotateUnlock.png and rotateLocked.png into your Resources folder in Xcode.Test it out
If you get stuck, start by taking a look at the example project included in the download.Download
One Touch Rotation Example Project and Source (1.0)iPhone Developers: Prepare Featured Artwork Ahead of Time
If you are an iPhone developer, I’d highly recommend preparing Featured Artwork files ahead of time. If Apple contacted you and wanted to feature your app, would you want anything to stand in the way of that happening? I received a brief email from Apple in early in August requesting artwork for a ‘potential marketing opportunity’. The opportunity turned out to be Read It Later being featured in the Apple App Store. The email came in late on a Tuesday and had requested artwork files for first thing Thursday morning. In reality, this gave me about a day to put everything together and send it. However, during that time I was scrambling to get some other work finished before I left for a trip at the end of the week. There was no way I was going to miss the chance for whatever this opportunity was so I ended up having to forfeit some other important tasks in order to make room for this. It would have been much better if I had this work ready to go ahead of time. In fact, details about having these files are in the ‘developer guide’. The guide is linked to from the bottom of the iTunesConnect window and the details of the featured artwork are buried near the end of the PDF. Admittedly, I had never seen it, and from the developers I spoke with, a lot of others haven’t either. I wanted to share my experience so in case other developers were not aware of this they could be better prepared than I was. Though it meant I had to put off some other work that week to put the files together, the result of being featured was definitely worth it.
The Requested Artwork
They request two artwork files. The Apple designers will actually take bits/pieces from these and rearrange them as they see fit based on the image they are trying to create. (More on that below)
Title Treatment - This is a 600 x 600 image of your logo/title. The background should be transparent and it should exclude tag-lines if the text will not be legible at a small scale.
An example of the Title graphic for Read It Later is shown to the side.
Background Treatment - This is a 900 x 530 layered PSD. What you put in this file is fairly open. Apple states: “The background image, texture, color or gradient should correspond to the application or compliment the title treatment. It may include elements of the application itself, but should not be or include screenshots.”
The approach I took was to provide them with a gradient background in one layer and then a main graphic that could accompany the logo.
My Submitted Artwork
Just as an example (you wouldn’t send this together), here is a close up of the combined artwork:
Apple’s Design
As I mentioned, Apple will take the artwork you send them and put it together in a way they see fit. You should try to keep all the graphical elements in separate layers in Photoshop to make this easier for them. If you have some graphic elements that must be laid out in a specific way, I’d suggest merging the layers so the designers do not break them apart as they will not consult you prior to the graphics being made. Here are the three images that I saw during the time it was featured. As you can see, they significantly rearranged the graphics I sent them. (I think they turned out nice, just making the point that this may happen).On the featured tab of the App Store App:
Big promo on the main App Store page in iTunes:
Mini promo on the main App Store page in iTunes:
Reverse Tethering
During my trip to Japan, I only had access to hard LAN connections (no WIFI). This meant that I could not connect my iPhone without using the expensive data connection.
That was until I realized I could use my laptop to setup reverse tethering. Meaning, I could use laptop’s internet connection through my iPhone.
The process could not be easier (on a Mac):
- Make sure Airport (wireless) is turned on
- Open System Preferences
- Select Sharing under Internet Settings
- Check the Internet Sharing box
- Select ‘Share your connection from:’ Airport
- Open your phone and connect to the new wireless network!
