Prime31 iPhone Applications » iPhone

iPhone 4 and iOS 4 Updates

Mike (admin) — Fri, 30 Jul 2010 02:59:00 +0000

We are just finishing up the final updates for the iPhone 4 and iOS 4. There are a ton of changes to Feeds, Tweets and a few for FileFly. All the images were redone for Tweets and Feeds so they look a TON better on the iPhone 4. We added fast app switching support to Tweets and Feeds as well. FileFly won’t be getting fast app switching support because it just doesn’t make sense to waste precious memory for no good reason. The final Tweets and Feeds updates should be heading out to Apple this week so everything should be looking much better on the iPhone 4.

Tweets – Twitter for the Rest of Us Preview

Mike (admin) — Wed, 10 Feb 2010 17:48:06 +0000

The last few months we have been hard at work on our next application. It is called Tweets and
as you can guess from the name it is a Twitter application. Why another Twitter application when there are already a gazillion of
them? We couldn’t find one that worked exactly the way we wanted. When we build apps it is first because we want to make something work exactly how we want it to. Most of the Twitter apps in the App Store do some things really well but none fit what we were looking for…until now. We borrowed some ideas from things we liked in a bunch different Twitter apps then we added the things we thought were missing and put our own spin on it all. The result: Tweets – Twitter for the rest of us.

Tweets is designed to be a fast, useable Twitter client. Some of our design goals are:

the things you do most often should be available in the least amount of touches possible (this one is pointed at most of the major Twitter apps. Having to perform 2 touches to click a link just doesn’t work for us. Twitter is full of links to websites, mentions, hashes (#somePhrase) and there is no reason why you should have to go to a second screen to be able to touch the link you want to go to.)
simple is better. Twitter is a huge system and distilling that down to what is useful in a mobile application is very important.
all actions should not need to be learned but should be readily apparent or easily discoverable even if it makes the UI a bit less ‘pretty’.
settings should be dead simple, there should be few of them and changes to them should take place immediately even while still in the application
maximize screen real estate for Tweets. Nothing extra should be present when on the main timelines besides the tweets you are reading and required navigation controls. This one is huge for us. Twitter is about the tweets, not the toolbars taking up tweet space.

An early release of Tweets is now being beta tested. We have gotten some great feedback and we have a few new killer features going in before the big release in a few weeks. We also have the first draft of the Tweets website live available at: http://www.prime31.com/tweets/ The screenshots will most certainly change as we nail down the UI as will the copy. Watch here for more news sometime around the 25th of the month.

iPad and iPhone Apps and the App Store

Mike (admin) — Mon, 01 Feb 2010 23:09:04 +0000

With the coming of the “Jesus Pad” (see previous post) Apple is threatening to shake things up yet again. This time it’s not the smart phone world that’s in for a rattling but the much larger world of personal computing. As mentioned in my previous post, apps are going to be a big thing on the iPad (Obviously. What good is an iPad with no apps). Developers have some big decisions to make about how they are going to create and sell their apps in the coming months.

Apple is providing developers with a couple different ways to get their apps out to the iPhone/iPod and iPad. Each has it’s own advantages/disadvantages along with a different set of benefactors and beneficiaries as well. Below I will describe what developers’ options will be along with their implications. First a couple definitions for those less word inclined individuals (like myself. I needed to look these up to not get them confused).

Benefactor: one that gives aid, especially financial aid.

Beneficiary: one that receives a benefit.

Universal Binary

A universal binary is a single application that will run on the iPhone/iPod Touch and the iPad. Mac users are more than likely familiar with universal binaries because they have been prevalent the last few years as the switch to Intel processors was occurring. Universal binaries had both an old-style Power PC and a new-style Intel build of the same application. The difference between Mac universal binaries and iPhone/iPod – iPad universal binaries is that developers were not stuck in the roll of benefactor for them. The application was identical for each architecture and the price was the same when selling either architecture. The same is not at all true for the current universal binaries on iPhone/iPod – iPads.

Benefactors: Developers

Beneficiaries: Apple and Users

Universal binaries have a number of difficulties for developers both from a programming perspective and a financial perspective. Creating a a universal binary requires a developer to spend the time to create a single application that will look great on both the iPhone and iPad. The screens for each of these devices is such a world of difference that there can really be slim to zero asset reuse. To take advantage of the iPad’s larger screen gestures will be different, images will need to be redone and new features added. Essentially a second application needs to be created. Some work can be saved in reusing code between the two formats but a large portion of code will need to be different if it is going to take advantage of the iPad’s feature set. All this takes time and it is not a trivial change to add features and full redesign an apps UI. Not to mention bug testing and making sure everything works as planned for both formats.

So how does this benefit users? Well, they just got 2 applications for the price of one. Developers will have to keep the price at iPhone levels if they want to get any sales. If developers raised the prices of universal binaries they would see far less sales than a similar iPhone only application with a lower price tag. Users also benefit in that it is just so easy to have a single app that will magically work on an iPhone and iPad.

Apple benefits because they get some more app sales and this could possibly even push users to front some cash for an iPad. What if users found a whole bunch of apps that they love on the iPhone and the iPad versions are already payed for. They might be swayed to purchase an iPad if they are on the fence.

Universal Binary

Huh? Didn’t we just read about universal binaries in the last section? You are not mistaken. You did. Here is a different and far less likely way the universal binary game can go.

Benefactors: Users (sometimes)

Beneficiaries: Developers and Apple

In this model, developers charge a higher price for universal binaries than they would have for an iPhone application alone because they took a lot more time to stick an iPad application in there. Why are users the benefactors then? What if you are user who doesn’t own an iPad an you will only be using the application on your iPhone? Why should you pay for the extra iPad features that you will never use? If things went this route (which I really doubt they will after the iPhones race to $0.99) iPhone app prices will end up being higher and a lot of people will be paying for a built in iPad application they may never use.

Separate iPhone/iPod Touch and iPad Binary

This is the opposite of a universal binary. A separate application would be made for the iPhone/iPod Touch and the iPad. Code can still be shared between the applications but there will be 2 distinct products for sale in the App Stores.

Benefactors: Users (kind of, but not really)

Beneficiaries: Apple and Developers (kind of, but not really)

This model makes application development easier on the developer. There is no need to pack two apps in one package that can share next to nothing UI related with each other. The benefactors and beneficiaries in this case really aren’t playing the roles. Users can be perceived to be the benefactors because they have to purchase two applications even though it is the same thing (in their eyes). This is a mistaken perception. Developers had to make two separate applications. The iPad version didn’t magically create itself. It took time, dedication, new assets and a whole new UI. New features were added to take advantage of the iPad. Developers deserve to get paid for their work. Let’s say you went to an art gallery and saw two amazing paintings that looked very similar but one was a bit smaller. If you bought the smaller one would you expect to get the bigger one with it for free? Of course not so let’s drop this expectation with iPhone and iPad apps before it event happens. Support your artist and you will get even more amazing work from them in the future.

Conclusion

It is readily apparent that Apple is always the beneficiary. Whichever model a developer chooses Apple is going to get a piece of the pie. I’m going to venture a guess and say Apple wants developers to make universal binaries. Universal binaries have the greatest benefit to them because they offer the potential temptation for users on the fence about purchasing an iPad (or iPhone) a bit of a push to do it. It may not be much but if it turns out to be enough in just a small percentage of cases that is another hardware purchase for Apple.

Developers are going to have to be very careful about how they proceed. They shape the prices of applications in the App Store and they pretty much blew it with the race to $0.99 for iPhone apps. I can only imagine the quality of an application that is a universal binary selling for a dollar. It can’t be good. Not for users and not for developers. If developers put some quality time into iPad ports of their apps they will be a superior experience for users and users won’t mind fronting a bit more money for them. On the other hand, if developers take the quick route and don’t fully rethink and redesign their applications then users will not want to buy them and they certainly won’t want to pay more for them. What I would like to see from Apple is some way to link separate iPhone and iPad apps together on the SKU level. I would like to see them offer a discount program so that if a user buys an iPhone app and wants to buy the same app on the iPad they get a price reduction. A system like this would benefit everyone: users would get kick-ass ports of their favorite iPhone apps for a discount and developers would have a reason to spend some quality time on the development of the iPad port to really make it stand out.

Developers have a need to be responsible with this process. If an iPad port isn’t much more work (think most games if they just use higher resolution textures or only have a few simple changes) then a universal binary at a fair price is in order. Granted, a universal binary is not an option if the iPad version of a game has a large amount of changes that took significant work to do. I wouldn’t expect to pay the price for a PSP game when I am buying a PS3 game.

Feeds Version 1.8 Off to Apple for Review

Mike (admin) — Sun, 06 Dec 2009 17:28:30 +0000

We sent off the newest build of Feeds to Apple for review. Hopefully it will take them less than a month to get this one out. This version contains the following:

You can now add a note to any article (if using Google Reader)
Fixed a crashing bug when deleting a folder
Fixed the ‘Get 20 more’ issue when show only unread was turned ON and it didn’t actually return 20 more

Enjoy!

UPDATE (12/11): In record time Apple has finished reviewing the update and it is now live. This marks by far the quickest update we have ever received clocking in at just 5 days. 2.5 weeks was the previous record and it has most often been over a month. Maybe Apple doesn’t hate us as much as we thought…or maybe they just forgot to tell the new guy to stick our updates on the back burner for a few weeks before looking at them.

Feeds Users not Using Google Reader for Syncing – OPML Export

Mike (admin) — Fri, 09 Oct 2009 03:00:33 +0000

This one goes out to all our users who have been around since the early days of the App Store. A long, long time ago Feeds didn’t sync with Google Reader and instead did all syncing through our servers. Once we added Google Reader support a HUGE majority of our users ditched the old way of syncing and in a way, so did we. All new features were made for Google Reader syncing only unless it was dead easy to add for old style users.We have highly recommended for a long time now that all old style users get on the Google Reader bandwagon. There are those that still have a ton of RSS feeds in the old world and don’t want to go through the torture of adding them to Reader manually. Lo and behold, this is no longer needed. We whipped up an OPML exporter for ease of transition to the Google Reader world. All you need to do is export your Feeds OPML file, import it into Google Reader and enjoy all the new features.

The OPML exporter is located at: http://ifeeder.prime31.com/export/opml/DEVICE_ID_GOES_HERE

Just replace the DEVICE_ID_GOES_HERE part with your deviceId and you will magically get an OPML file that *should* work with Google Reader. Enjoy!

Feeds 1.8 Sneek Peek (if Apple ever finishes reviewing the 1.7 update)

Mike (admin) — Fri, 04 Sep 2009 21:07:13 +0000

Since Apple has taken over a month now to review version 1.7 of Feeds we have been busy preparing version 1.8. 1.8 is probably the biggest update yet besides when we added Google Reader syncing a loooong time ago. There are a few screen shots below to let you see the visual changes we made. The internal changes that I can remember off the top of my head are:

The ‘Show only Unread’ feature will now hide feeds and folders that don’t have any read items
Reordering of feeds and folders for Google Reader (Note: changing the order in Feeds will not affect the order on Google Reader)
Better InstaPaper integration. Feeds will not prompt for and remember your password so you only need to enter it once.
Better ReadItLater integration. Same as InstaPaper, Feeds will ask for your login info only once and then remember it. You no longer need to go into Settings.app to enter your login info.
Visual overhaul. We changed the look and feel a bit because Feeds was looking a little bit dated with an emphasis on performance so there isn’t too much visual flair.
Actual website favicons are displayed (when available. RSS feeds that use aggrigators such as FeedBurner will not have their favicons present).
If you have 3.0 installed you will get to use the standard Apple Mail.app compose message right inside Feeds.
You can now post to Twitter a message that can (if you want to) include a shortened version of the articles permalink.
When viewing a list of articles, you can send an email with all the articles including their permalinks and preview text.
The much needed Help button has been added (pay no attention to the ugly icon placeholder in the pic below)
We removed a bunch of settings from the Settings.app to simplify things.
You can now back sync as far as 5 days (not suggested. It WILL be slow).
You can now set the number of items per feed to save as low as 25. This speeds things up for those who have a ton of feeds.
Blue is now the default theme color.
A few bug fixes here and there

We apologize about the delay with 1.7 and really hope Apple makes some changes to their review process. Not to gripe, but in the time Feeds has been in review (since July 2nd) three updates to Facebook have been approved. Favoritism? Unfair review practices? You be the judge…

And now some screenshots:

UPDATE: we pulled the previous version 1.7 that has been in review since July 2nd yesterday and replaced it with this version. Version 1.7 will now be the version in the images above. We are hoping that resubmitting won’t add any more time the review process (is it possible to add any more time at this point?). Maybe the last update we sent to Apple got ‘lost’ over there. Who knows? Not us, that’s for sure.

UPDATE: Apple just approved version 1.7! We are already aware of 2 bugs and we apologize about that. The rushed cycle due to our last update not being accepted after 6 weeks caused us to get a bit itchy on our trigger fingers. The 2 bugs we are aware of only affect landscape mode so hopefully it won’t affect too many people.

Feeds – The Next Minor Update

Mike (admin) — Fri, 24 Apr 2009 15:46:00 +0000

UPDATE: ReadItLater seems to be working well and our testing of the other changes is complete. Feeds version 1.5 is now in Apple’s hands.

We are wrapping up testing on the next update now. There isn’t too much to report on this one. There are a couple additions and we are starting the process of removing some settings as well.For the additions, we are adding ReadItLater support. There will be a spot in Settings where you can put your ReadItLater login and password so if you don’t have a ReadItLater account now is the time to secure your username. Apparently ReadItLater is getting popular really quickly and we didn’t want to be left behind.

Also added in the update is a toggle to turn off the features that use shaking to activate. We also make it require a bit more effort to get the shake to be recognized so that we can avoid false positives.

Probably the most significant update and also the most elusive is a small change we made to attempt to remedy some syncing issues. Without getting into too much detail, currently Feeds will ALWAYS grab the freshest unread count from Google every time you start it up. Feeds does not always do a sync though. Currently, if the ‘Refresh Feed Items’ setting time has not elapsed Feeds will not fetch the new items. This leads to the unread count being slightly different (or very different depending on the RSS feeds and the interval set) than the number of actual unread items. All this dies on this day. Feeds will sync each and every time you start it up. We are no longer going to worry about the data plan you are on and trying to penny pinch the couple kilobytes of data. The complaints far outweigh any benefit in us trying to be frugal with the feed updates. This is the first step in eradicating all the confusing options in the Settings app. More to come.

Google Reader Integration Status

Mike (admin) — Thu, 11 Dec 2008 19:19:39 +0000

After a hiatus to Japan for 2 weeks we are back on the prowl getting Google Reader integration wrapped up. As we work through adding functionality we are of course coming to some roadblocks that are requiring us to make some decisions on what to include and what to scrap. The biggest problem we are having is with offline mode and synching properly when there is no internet connection. Unlike the non-reader part of Feeds, we don’t have a way to ask Google for all posts that came after x. We instead, have to download a whole bunch of extra posts which is quite slow over Edgel

The best proposal that we have come up with so far is the following: add an option to the Settings screen that would toggle online/offline mode. If offline mode is selected, each time Feeds is opened if there is an internet connection available it will download and store a user definable number of items per feed to store for use offline. If there is no connection available, Feeds will just pull from the already downloaded items. One drawback is that Mark All Read will not work in this mode because when you are online again and we go to sync with Google, the “All” part can be quite different that it was when the button was touched.

When using online mode, Feeds will not pre-fetch any feed items and will only retrieve items if requested. This will speed up application startup and there will be no delay for syncing either. It’s only drawback is that it request an internet connection which for almost all of our users isn’t a problem.

If anyone has any feedback on what you want to see leave it here.

UPDATE: An anonymous user gave us a little tip that basically makes this post irrelevant. We will give some more information on our findings in a few days.

Providing Your iPhone Device ID to a Developer

Mike (admin) — Mon, 11 Aug 2008 15:54:33 +0000

On occasion when submitting a bug for an iPhone application you will be asked to provide a Device ID. This is a 40 digit alpha-numeric code that represents your iPhone. Providing the Device ID allows developers to look for errors or other oddities in log files on our servers. This can prove to be instrumental in finding bugs/errors that had previously gone unnoticed.

Below are the instructions on how to get your Device ID so that you can email it if asked.

Open iTunes and connect iPhone
Click “serial number” label. It will change to Identifier
Choose from the file menu: Edit -> Copy. (This will put the device ID in your clipboard so you can paste it)
Paste the device ID (Edit -> Paste from the file menu on top of your screen) into the reply to this email

Here are a couple pictures showing where to find the Device ID: