2011 is coming to a close, so I'd like to take a moment to highlight a few apps and games on Mac and iPhone that have been invaluable to me. I broke this out into four categories, each with two apps. I have purposely omitted iPad, because frankly, I rarely use my iPad (and I prefer the TouchPad over the iPad), and don't feel I've played with enough iPad apps to really give it a fair shake. So I've left that off to focus on iPhone and Mac apps and games. I hope you'll check out all of these great apps.

DISCLAIMER: I am friends with the guys at Tapbots (makers of Tweetbot) and the guys at TapTapTap (makers of Camera+). However the apps would not have made it onto the list if they were not of the highest quality, and have not influenced my reviews. I have deliberately excluded apps made by any company that I have worked for either now or in the past. I have also not included affiliate links.

Best iPhone Apps

Tweetbot

$2.99 - Tweetbot came out this year as a pretty full-featured Twitter client, but naturally everybody has their own pet features they would like. The guys at Tapbots have steadily improved the app over the year, adding support for push notifications, muting, Favstar integration, and plenty more. It has since become the best designed and most full featured Twitter client, far exceeding Twitter's iPhone app.

Camera+

$0.99 - The iPhone has the best camera of any mobile device (and I test a lot of mobile devices). Camera+ has many features that go beyond the included Camera app. The most important ones actually help you take better photos, such as the image stabilizer, which uses the iPhone's gyroscope and only captures a photo when your hands aren't not shaking. The touch up tools are very handy, and the filters look pretty good compared to other photo apps. And a suite of sharing tools help you share your moments with your Twitter, Facebook, and Flickr friends. It's the tool you should reach for when taking photos, and it shows how good a replacement the iPhone can be for a standalone camera.

Best iPhone Games

Super Stickman Golf

$0.99 - I'm a sucker for a good physics game, and Super Stickman Golf is a great one. Get the ball into the hole while navigating steep terrain, dodging death traps, and staying under par. With dozens of 9-hole courses and a grab bag of power ups, there is a ton of replayability here. It also includes an exhilarating multiplayer mode which completely changes the mechanics from precision to speed. One of the greatest physics games for iPhone that isn't just another Angry Birds clone.

Jetpack Joyride

$0.99 - The form factor of the iPhone lends itself to simpler games over more complex ones. One-tap games like Canabalt are great because of their simplicity. Jetpack Joyride takes this to great lengths, packing a ton of variety into a single tap. And it shows how to do free-to-play games right, in a way that doesn't give an unfair competitive advantage or make you feel forced into spending more money. Gorgeous graphics with a ton of tiny nuance help seal the deal.

Best Mac Apps

Spotify

Free w/ optional subscription - Spotify combines a cloud-powered streaming music service, a lovely native Mac app, and excellent sharing features into one great app. Though Spotify has been around for awhile, it only recently became available in the US. It lets you combine their huge streamable catalog with music in your iTunes library. It syncs your playlists in the cloud, and copies tracks to your iPhone via Wi-Fi. And it lets you share tracks and playlists, either to one person or the world, quickly and easily. I've ranted before about how I don't like iTunes, and have searched long and far to find a suitable replacement. This year, Spotify became that replacement.

Pixelmator

$29.99- Photo-editing tools typically come in one of two favors; way too complicated, or way too simple. Pixelmator bridges the gap by bringing much of the power of Photoshop to mere mortals at an affordable price. While pro designers probably won't drop the Adobe tools for it, it's a fantastic and flexible tool for editing photos. And it has great support for core Mac OS X technologies like Core Image and Auto Save. It's the perfect tool for going beyond red-eye reduction and one-click canned filters to make photos and images look fantastic.

Best Mac Games

Minecraft

$26.95 - Not many games have staying power for me; I typically lose interest in most games after a couple weeks. Not Minecraft. I started playing Minecraft in September of 2010 and have been continually coming back to it ever since. A Lego-style deformable terrain lets you create the world in your image, getting lost in massive caves, and dodging monsters who hunt you down and try to kill you. The game has incredible depth, forcing you to find raw materials and learn how to turn them into weapons, armor, building materials, and so much more. If you've got some friends who play, and one of them is technically savvy, you can set up a multiplayer server where everyone can contribute to the same world, helping each other survive and creating ever-cooler worlds. The 1.0 version, released in November, has a series of objectives and an end-game, though you can happily ignore it and just have fun making your world. You'll spend hours playing Minecraft, and actually have something to show for it after.

Galaxy on Fire 2

$19.99 - One dream that will probably go unrealized in our lifetimes is that of interstellar space travel. We've all wanted to live out battle scenes from Star Wars. Galaxy on Fire 2 is a gorgeous space action game that brings that to life. You can hunt pirates, trade minerals, go on side quests, and hunt down the mysterious race known only as the Voids. A large economy lets you customize your ship to give you the edge in battle, or help you carry more precious resources across the galaxy. A massive story, incredible graphics, great voice acting, tremendous depth, and perfectly-tuned controls make this a must play. It's available on iPhone and iPad, but with so much graphical detail, you'll want to check this one out on the big screen.

, , , , ,    Tags
 

iCloud looks like it will be an incredible technology for moving app data between devices. This is inherently a good thing, and it will open avenues for many new types of apps. But, there is a fundamental problem. Right now, the only way to access it is through Objective-C APIs embedded into iOS and Mac OS X. Under the hood, they are obviously talking to the network and doing the business of syncing data, but that networking layer is not exposed or documented, and would have to be reverse-engineered in order to understand and use. So the only way for developers to move their data through this system is through a pre-compiled bundle that gets referenced within an application.

This has a few interesting practical repercussions. If you build an application targeting iCloud, you can only ever put it on two platforms - Mac and iOS. You will never be able to port it to Android, WebOS, Windows Phone, or the web (mobile or desktop). If you sync data through iCloud, And, you will never be able to have a server component that can do things with your data all the time.

Here's some examples of what I'm talking about. In my To Do list app, Todolicious, one thing I would love to be able to do is to push badges to your iPhone and Mac showing the number of To Dos you have left. When you tap a To Do to mark it as done, suddenly all your devices would show the correct number on the icon. With the sync server I was building, this was fairly trivial; wait for the user's list to change, and send a signal to push the count everywhere. But if I back Todolicious with iCloud, I have no way of speaking between my server and iCloud (and I'd still need a server of some kind to send the notifications, after all).

Similarly, if I were to build a web app version of Todolicious (which I was planning on), I could not get access to that data within iCloud at all. I'd have to have either to sync to both iCloud and a custom solution (unwieldy, poor UX and network traffic, and otherwise gross), or not load existing data at all (completely negating the benefit of having such a web app).

So there is a serious ecosystem lock-in problem for apps that wish to target iCloud. All of these problems go away when iCloud is made available as a server-to-server API. A big benefit in the promise of cloud computing includes service interoperability, but right now iCloud is merely a data silo. I have filed this as a bug, rdar://9598555, for a server-to-server API (through which you could build code that speaks to iCloud on your server or on other platforms). I dearly hope Apple addresses it.

Such a server-to-server API would drastically decrease the friction of setting up cloud services to complement an iCloud-backed app, and would lead to better apps and more pleased users.

 

Two years ago, I began working on a new Twitter client for iPhone, named Streamlines. I hinted at it about a year ago, and has been a driving force in my development of MGTwitterEngine and a ton of open source projects. I've come to the conclusion that I won't have time to finish and release it, as there's still probably another 6 months of development needed to really ship it, and hostility from Twitter and from users of other Twitter clients make effort into building one unsustainable. However, I think there are UI concepts in there which are totally unique and have never been seen before, so I'd like to share them with you before this project is lost to the annals of dead projects.

Here's a video walking through some of the main UI concepts found in Streamlines.

Streamlines is a social networking client that is designed to show you what you want to see, and hide what you don't care about. To do this, it avoids using tab bars and navigation stacks, and instead uses a card interface with a horizontal swipe, similar to the iPhone's Weather app or WebOS' multitasking UI. You pick which timelines you want to see.

On top of that, you can merge multiple timelines together, across all types of timelines, accounts, and services. For example, if you use Lists on Twitter and Facebook to organize, say, your family members, you can create one contiguous timeline which combines both those lists and shows you what your family members are doing, regardless of where they posted it to. Or, you can combine your Twitter followers, mentions, and direct messages together, similar to how Twitterrific works. This saves you time, as it lets you create your own timelines which show you new perspectives on your social networks that you simply can't get with most Twitter clients.

Streamlines tries to make sure you always are looking at the best data, so for every tweet you see on screen, it will update the relative date in real time. So if a tweet is 6 seconds old, it'll update live to say "6s", "7s", "8s", etc. The time is always up to date, so you know how long ago someone actually posted something. Streamlines accounts for API rate limiting, using some advanced heuristics to schedule API requests so that you never run out. This was more a problem two years ago, when you had 30 API requests per hour shared across all your Twitter clients, but still handy. And it handles incoming and outgoing attachments, so if you or someone else embeds content from another site, Streamlines will replace the URL inline with a preview of the image or video.

Under the Hood

Streamlines is backed by two frameworks I wrote, BirdNest and BirdNestUI. They're frameworks because, well, I actually have about 8 apps which use the same Twitter source code, spanning iPhone, iPad, and Mac. This framework tries to encapsulate a lot of functionality - it includes multiple accounts (with credentials stored in the Keychain) spanning multiple services (Twitter and Facebook, with plans to expand into other timeline services like Google Buzz, Foursquare/Gowalla, Yelp, etc.), networking, persistent data, and lots more. It's powered with Core Data and has about 12 open source projects which make up various pieces. The UI framework contains views for showing and creating accounts and timelines, creating tweets or wall posts, and showing timelines in tables (and there's a corresponding UI framework for Mac).

Why Won't It Ship?

There are many reasons. First and foremost, it's at least 6 months out from being released, and that's optimistic. There are lots of bugs, crashes, and UI problems alone, not to mention whole views just not having been built yet. So there's a huge body of work still to be done. I haven't had much opportunity to work on it recently, and there's not much to suggest I'll have more soon.

On top of that, building a Twitter client has become far less appealing than it was two years ago. In those two years, Twitter has drastically increased their feature set to include a TON of things, including geolocation, native retweets, and lists to name a few. The only way to remain competitive is to iterate extremely fast to include every new feature, whenever Twitter announces them. At the same time, Twitter has made several very hostile moves to make it even less appealing to develop on their platform; the most egregious of which was the acquisition of Atebits and their Twitter client Tweetie. There's now such tremendous market saturation for Twitter clients, especially on iPhone. Releasing a new Twitter app now is difficult, as nobody really pays attention to new Twitter clients any more.

Competing with Twitter's free app is hard enough. Even if I could get it to market, there are tons of users who will demand that every feature Twitter offers be crammed into every new release. And everybody's list of must-haves is different; some people will only care about lists, and will rail on you if they can't edit lists. Some will only care about the geolocation feature and if you can put that on a map. Some will only care about native retweets and seeing a list of people who retweeted. Every one of those features, to these users, is a line item on a checklist that needs to exist. To a developer, every one of those features can take weeks or even months to build properly. But every one has to be in there. Oh, and all of those features need to coexist, cleanly, on a small screen, with a fantastic user interface. It is an insanely complex problem to solve.

All of which needs to be built for an app that will not receive much attention, that will be crowded out of the market and will need to be priced cheaply to compensate, and that will be overshadowed by Twitter's own app anyway. There just simply isn't much reason to build a Twitter client anymore. I would much rather spend my time building an app that users will judge for its own merits, not for its completeness in binding to another service.

Going Forward

I'm not sure what to do with Streamlines as it is today. I do think there is a market for niche apps which use Twitter, and I still have some intention of bringing those to market. But I can't say when, and if they ever come, they will not be full Twitter clients.

I'm considering open-sourcing the code, but I'm not convinced of its practicality yet. I'm hesitant to think that someone will want to adopt a monolithic framework for building their own Twitter apps. It's possible they do. But the code is not the cleanest, and there are surely lots of bugs.

That being said, if anyone wishes to build an app with a similar interface, they have my full blessing and encouragement to do it without any permission from or attribution to me needed. I'd like to see more variance in Twitter client UI in general, as the tab bar metaphor is pretty worn at this point.

I would love to hear any and all feedback, positive or negative, either by Twitter or by leaving comments on the YouTube video above. Thanks for watching and reading.

 

For a little less than a year, I've been writing code built atop Twitter, specifically Matt Gemmell's MGTwitterEngine. I've got a few things running on this code, which I've not talked about publicly (other than minor hints on Twitter), but have been well-received by the few people who have seen it. Still, these projects have needed to extend both MGTwitterEngine and related libraries to add functionality or fix bugs. I'll spend this blog post documenting some of those changes across the different projects.

MGTwitterEngine

Most of these changes were made to make the engine's behavior a bit more extensible. Here's the GitHub repository.

  • MGTwitterEngineID is a typedef for unsigned long long values. Everywhere a user ID or tweet ID is returned, it will return one of these. You will want to check your existing Twitter code to make sure there are no potential Twitpocalypse-related problems, updating old data types to the new MGTwitterEngineID.
  • Subclasses of MGTwitterEngine can now override a new method, -_sendRequest:withRequestType:responseType:, if they want to use custom networking code (such as with an NSURLRequest queue class). I use this to implement both Twitter's password authentication and OAuth, and decide at runtime which to use.
  • Added a -connectionStarted: method to MGTwitterEngineDelegate, which can be used to update your UI.
  • Fixed a few bugs in the YAJL parser which crashed or parsed incorrectly.

Things I still need to do:

  • In my custom subclass of MGTwitterEngine, I use a class I wrote called TCDownload, which I'll talk about below. There are still a few references to it in my MGTwitterEngine class; those should be fairly straightforward to remove. Update: Thanks to Uli Kusterer, the dependency on TCDownload has been removed. The changes have been merged from his fork into mine.
  • Add full support for Twitter lists. I have some basic Twitter list functionality working in a private subclass, but far from all of it. There are some problems with the YAJL parser that don't appear easily fixable with the stock MGTwitterEngine (specifically, the API key for the list description is the same as the key for the user's bio, and these are overwriting each other internally). I'm going to look into replacing the manual parsers
  • Add full support for new-style retweets. Haven't started this yet.
  • Add support for geolocation in incoming and outgoing tweets. Haven't started this yet.

yajl

I've forked yajl to support 64-bit tweet IDs, mainly by changing the callback methods and the string parser from strtol to strtoull. Here is the GitHub repository.

SSCore

This is a repository of scattered classes which serve various purposes. There are two classes which are relevant for our discussion, TCDownload and TCOAuthDownload. You will need the TCDownload class if you use the vanilla MGTwitterEngine fork, although I'll be removing those dependencies. Here is the GitHub repository

  • TCDownload is a generic wrapper that encapsulates an HTTP request to the interwebs. It wraps NSURLRequest and NSURLConnection under the hood. It automatically queues request and gets callbacks on a background thread (although you can change either of these). I use it a few places inside my MGTwitterEngine fork, but removed most of those changes and put them in a subclass.
  • TCOAuthDownload is a subclass of TCDownload which accepts OAuth tokens and sends out requests with the correct headers. It relies on the OAuthConsumer framework, which I'll talk about below.

OAuthConsumer

This framework deals with OAuth. Twitter has officially announced that basic auth will be dead in June 2010, so getting on the OAuth bandwagon now is a good idea. Here's my fork of the OAuthConsumer framework on GitHub.

  • Changed the signature code to use Common Crypto instead of the C libraries' HMAC APIs. This seems to work more consistently on both Mac and iPhone.
  • Added a -parseHTTPKey:value: method which is used to parse extended attributes in OAuth access tokens. Twitter uses this to pass some special metadata, like the username of the logged-in user. Subclasses of OAToken can extend this to parse those tokens.

OAuthery

This isn't strictly a tool for doing Twitter development, but it can be handy when learning how to implement the OAuth login flow. I posted about it more back in January, and you can find the code and a prebuilt app over at GitHub.

Status:
 

We've all got our thoughts on what the Jesus Tablet will be, so here are my guesses. I fully expect to be completely wrong on all of this, as many of these answers are completely blind shots and that Apple will blow my expectations out of the water.

Hardware

  • 8"-10" touch screen, running at 1280x720
  • Very thin; less than 1/2" thick (the iPhone 3GS is 0.48" thick)
  • About 1lb heavy, light enough to hold in one hand
  • 8 hours of battery life
  • 32 or 64 GB SSD
  • WiFi
  • 3G over GSM, and Apple's US 3G partner will continue to be AT&T
  • There will be some way to pair your Tablet cell connection with your iPhone's cell connection; either with an official announcement of AT&T tethering, or by adding your Tablet to the 3G account
  • Front-mounted camera
  • Some kind of collapsible stand in the frame, so the device can sit on a table

Input/Output

  • Multi-touch on the display, exactly like the iPhone
  • Multi-touch on the back of the device, similar to the surface of the Magic Mouse
  • Photos and video via front-mounted camera
  • Audio via front-mounted microphone and speakers, wired headphones, or Bluetooth
  • Dock connector
  • Expanded voice recognition
  • Software keyboard, no Bluetooth keyboards available

Software

  • It will run the iPhone OS 4.0; or rather, the iPhone OS will become a "Mobile OS X", consisting of the heavyweight Tablet and the smaller iPhone.
  • It will allow multiple apps to run at the same time, with some UI for viewing multiple apps alongside each other. This may not be possible on the iPhone.
  • It meant to replace a full PC for most common day-to-day needs
  • iPhone applications will not run "automatically", but will need to be resubmitted through the App Store approval process. Most applications will run without much modifications. Icons will need to be higher resolution.
  • A system-wide Dock for documents, applications, and small widgets will be onscreen at all times
  • The home screen will be significantly revamped, and renamed to the Dashboard. App icons, web clippings, and widgets will be freely arrangeable.
  • Handwriting recognition will be available for text input, with an optional stylus, or with a gesture such as two closed fingers drawing as if you had a pen.
  • Some gestures will be used on the back of the device, such as scrolling and zooming.

Apps

  • Standard kind of iPod and Internet communications apps the iPhone OS comes with. iTunes video, iTunes LP content, Maps, and Safari web content will look phenomenal.
  • Sketchbook, an unlimited workspace to sketch and write notes, with collaboration features.
  • iWork, a full port of the iWork application suite, tied to the Internet (and expansion of the iWork.com web application), with collaboration features.
  • iChat, a port of the Mac app, with a heavy emphasis on video conferencing

SDK

  • The SDK will be available immediately, with a simulator.
  • There will be an emphasis on application interoperability.
  • Applications will be able to register plugins with view controllers and UTIs. When an application wants to expose an object (say, an image) to other apps, it will look for app plugins which respond to the "public.image" UTI, load one which matches the UTI, and present the view without leaving the application.
  • Applications will be able to expose services, similar to how they work on Mac OS X. Services will be integrated into the voice control system.

Product

  • 32 GB model will be available for $899
  • 64 GB model will be available for $999
  • Available in US in March, major countries by summer
  • There will not be a WiFi-only model at launch.

Other Predictions

  • Updated MacBook Pros and MacBook Airs, with the mobile Core i5 "Arrandale" processors from Intel.
  • There will be no mention of Verizon
  • There will be no updates to the iPod or the Apple TV
  • There will be no announcements of the iPhone 4G
 

Beyond impressive. This is more than some governments have contributed so far.

, , ,    Tags
 

Ars Technica:

ChangeWave queried 4,068 current and potential smartphone consumers last month and noted that a full 21 percent said that they would prefer Android on their next smartphones—a jump of 15 percentage points from the year before. Comparatively, 28 percent of respondents said they would prefer iPhone OS; this makes the iPhone the leader in this category, though this number dropped four percentage points year over year.

Many iPhone developers and Apple enthusiasts are quick to shrug off the Android platform, for a variety of reasons ranging from aesthetic and design, to functionality and developer tools. Many of these criticisms are certainly valid. But iPhone has its own share of problems, and certainly is deficient in many ways to the Android.

With Google's press conference tomorrow, and CES for the remainder of the week, there will be a lot of focus on the Android platform. It will become a much stronger platform in 2010. It will be interesting to see how Apple responds with iPhone OS 4.0 (which history suggests they'll probably talk about in March).

 

VillainousStyle is a drawing library for defining a visual style from a chain of individual drawing instructions. Each instruction modifies the drawing context to perform common operations; such operations include shadows, fills, borders, and shapes. It allows for multiple style sheets which can be used to theme an application in multiple visual contexts. VillainousStyle sits on top of CoreGraphics, and does not use WebKit for rendering at all. It is a fork of the VSStyle and VSShape classes, originally from the Three20 project.

Stylesheets

VSStyleSheet is an abstract superclass for a set of styles. Subclass it and add methods for each style you wish to add. You will likely want to create a protocol for your styles to implement, to ensure that your stylesheet implements all the necessary styles.

There is a global stylesheet, which can be thought of as the "active" stylesheet. Call +[VSStyleSheet setGlobalStyleSheet:] to change the active theme, which will fire a VSStyleSheetChangedNotification. When that gets fired, you'll want to tell your views to update their styles and redraw.

Styles

Styles affect drawing and positioning. Most will affect the next VSStyle objects in the chain.

  • Fills
    • VSSolidFillStyle - Fills the current shape with a solid color
    • VSLinearGradientFillStyle - Fills the current shape with a gradient between two colors
    • VSReflectiveFillStyle - Fills the current shape with a glossy-style gradient between two colors
  • Borders
    • VSSolidBorderStyle - Draws a border around the current shape with a solid color
    • VSBevelBorderStyle - Draws a beveled edge border for a 3D effect around the current shape
    • VSFourBorderStyle - Draws a border around the current shape with four colors, one for each edge
  • Shadows
    • VSShadowStyle - Draws a shadow behind content with a given color, blur, and offset
    • VSInnerShadowStyle - Draws a shadow inside the content with a given color, blur, and offset
  • Positioning
    • VSBoxStyle - Adds a margin or padding to the content area
    • VSInsetStyle - Adds edge insets to the content area
  • Content
    • VSTextStyle - Draws text inside the current shape
    • VSImageStyle - Draws an image inside the current shape
    • VSMaskStyle - Clips the drawing area to an image mask
    • VSShapeStyle - Clips the drawing area with a VSShape object

Shapes

Shapes affect the fills and borders, but do not clip the content styles.

  • VSRectangleShape
  • VSRoundedRectangleShape
  • VSRoundedLeftArrowShape - a rounded rectangle with a left-facing arrow
  • VSRoundedRightArrowShape - a rounded rectangle with a right-facing arrow

Future Ideas

  • iPhone static library
  • Cappuccino library
  • File-based stylesheets that can be read/written from VSStyleSheet objects
  • GUI builder for styles
  • More styles!

Status:

Active

 

The templates that ship with Xcode are not the greatest. Some of them are inconsistent and don't enforce good coding standards (e.g. missing a dealloc method). Other templates which would be useful just flat out don't exist (e.g. an NSOperation subclass, or a protocol header file). This project aims to supplement or replace the built-in templates for Xcode to speed up coding and improve the quality of code.

Coding Standard

All files will be processed by Xcode. The generated source files must produce consistent, readable, commented code. The code must have these characteristics:

  • Each file must have a comment block at the top describing the file.
  • Each class must implement its superclass' designated initializer and dealloc.
  • Stub methods must be organized by their purpose, class or protocol. -- Each group must be organized by their class hierarchy, with protocol stubs following. -- Each group must be prefaced by a pragma mark naming the class or protocol the methods were implementing. -- Clusters of methods (such as relating to KVO) should be organized along the lines above, with a pragma mark.
  • All method implementations should contain a method call to their super implementation if needed.
  • All method implementations should contain a commented out stub line that will signify where to insert their code.
  • All comments must be in the form of two slashes //, and none using the /* */ form. This will allow developers to comment out large blocks of code as needed.

Wish List

  • Different people want different things in their template. For instance, someone may want to include an implementation of observeValue:... for every class. Would be nice to have a template generator application (yeah yeah, very meta) which would make templates customized to the developer.

Status:

Inactive

 

URL Shrink is a new OS X tool with a very simple purpose - converting URLs to shorter permalinks on various web services. As the internet has matured, and services like IM, IRC, and Twitter have forced us to write shorter messages, it was clear that a system was needed that was as ubiquitous as Quicksilver.

For now, the main service of URL Shrink is just converting a URL that is on the clipboard, although this will be expanding over time (including things like a system text service, a command line client, a Quicksilver plugin, etc.). To do this, there is a keyboard shortcut (option-shift-space) which will convert the URL in the background to a tiny URL using one of the services provided. If you've selected one as your favorite, it'll choose that one. For example, I'm personally partial to is.gd, so all the URLs that are processed by URL Shrink on my machine go through is.gd.

At a low level, URL Shrink is a system where multiple shrinking engines can be added. It was designed to be extremely easy for developers to write just a little bit of code to integrate with other web services, including private URL services. For information on that, see the project page below.

URL Shrink is licensed under the BSD license. I encourage its adoption within other applications; I'll be adding .framework and .a targets for building this into Mac and iPhone apps respectively. Indeed, the project was born out of the URL shrinking capacity of another app I'm working on.

Status:

Inactive

Page 1 of 2