There are some interesting rumors coming from the usual suspects, suggesting that Apple’s fall product update will not only bring the expected iPod refresh, but also a new Apple TV that may be called iTV. The interesting piece of that rumor is that the new set-top box may include the A4 processor and run on iOS 4.

Such a product would be consistent with Apple’s product strategy and even if some voiced some disappointment that the iTV may be stuck at 720p, there is the logical assumption that it will connect to the App Store. And if it does, it will open up apps to even larger displays than the iPad – your TV. Imagine running your app on a TV. What could it do? What about casual gaming on a TV? It’s entirely possible with an iOS-based iTV.

We may be speculating a bit here, but we believe that Apple will continue to eliminate the borders between different types of devices and eventually allow mobile, desktop and consumer electronics to access the App Store. The implications for iTV include the fact that the box may be bridging the gap into the gaming world and turn into a game console as well. If so, imagine iPods or iPhones to be used as game controllers. There is a whole new opportunity out there, provided Apple will take this step, which we do not know for sure will actually be the case.

However, it may be a good idea to start thinking about Apps that run on much higher resolutions than on the standard iPhone and iPad screen.

Facebook has updated its SDK for iOSfor iPhone, iPod Touch and iPad apps. The big news is that this new SDK enables the use of the Graph UI and allows authentication with OAuth 2.0.

According to Facebook, more than 150 million people are using a mobile version of Facebook and the company intends to take its mobile app environment closer to where its desktop development stands.

Facebook said that it encourages developers to upgrade to the new SDK, but it will continue to support the older SDK for the “foreseeable future.” You can download the kit and find all information here.

I am not quite sure how often Flash has been discussed on the iPhone and how often we have seen prototypes running on it. Given the development of HTML5 as well as the memory and battery issues that come with Flash, Flash is turning out to be a nice-to-have feature and not so much a must have. But if you really must run Flash on an iPhone, now you can, thanks to Frash that runs on jailbroken iPhones. We haven’t tested it yet, but we thought you would like to know. If you run it, keep in mind that Comex says that Frash is not what you would describe as stable.

Of course, there is now an interesting legal situation that legalizes jailbreaking, even if such a move still voids the warranty of the iPhone. We doubt that Flash will become a major deal on the iPhoen, but it is worth watching whether this story develops.

Apple is unlikely to change its opinion and if you forget Mark Papermaster’s departure from the company, it is rather quiet about the phone lately. Despite the success of Android, Apple appears to be still selling every iPhone it can make and the Apple Store still says that there is a delay between your order and actual delivery. Sterne Agee analyst Vijay Rakesh this morning told investors that Apple is likely to address this situation, especially since the iPhone 4 is making its way to a total of 88 countries by the end of September. Q3 orders have been increased to more than 10 million, according to Rakesh, which would translate into a 20% production increase over Q2.

We should see data and app use still increase over the next months. For those of you who are keeping track of the numbers, Google recently said that Android is selling some 6 million phones every month now.

Demo versions have always been a big part of software download stores on the Internet – just not so much for the App Store, which in the end, created an environment of “lite” versions and, if we believe Mashable, also software piracy. Piracy is unlikely to go away entirely, but there is now a new try before you buy section in the App Store that may discourage piracy somewhat. And, Apple quietly introduced Genius as a new feature for the App Store.

Apple was never especially receptive for demo versions and that has not changed yet. However, lite versions are now specifically available in a try before you buy section. You can always argue what may have prompted Apple to introduce the feature. Perhaps it was just about time, considering the fact that there are more and more users and more and more apps – and sometimes you just don’t want to pay before you have not seen what an app can do. Mashable, however, believes that Apple may think that this category may prevent a scenario of would-be pirates – users who just don’t want to pay before they have tried the app.

The iPad App Store now has a Genius tab, enabling users to find new apps depending on the Apps they already have. While the feature was added quietly and there isn’t much information available, it appears that the Genius feature only recommends apps with a 2-star rating or higher. That is rather unfortunate for those apps that do not have a rating yet, but surely helps to get to the higher quality apps first. However, it means that good ratings will get even more important for apps and while the Genius feature is marketing help provided by Apple, it requires that you do your homework first – and get a good rating in the first place.

For those who keep count, there are more than 225,000 apps in Apple’s App Store.

This one seems to be a bit early. It isn’t quite Apple rumor time and it surely is not the time for a new iPhone to be discussed. Or is it?

The whole iPhone 4 antenna drama has spawned a new round of rumors, iPhone 5 rumors. One of those industry sources suggested that Apple is pushing up the release of the fifth generation iPhone up to early January 2011 to deal with the antenna issue. Sort of a redesigned iPhone 4. That is a tough one to believe, but then we never know. By the way, Apple just deleted the antenna performance comparison videos from its website. There was no information why that happened, but we think it is a good idea. A justification has never been really necessary anyway.

Besides the new iPhone 5, rumor has it that there will also be a smaller iPad with a screen size of seven inches. The source also talks about an iPod nano, a shuffle with a small 1.7” screen as well as the new iPod touch. There is one more product update cycle in September and there is no doubt in our mind that Apple will be updating its iPods then. It will be interesting to see how far Apple will take its iOS, whether it will make it into the nano or whether Apple will put a much stronger focus on the touch, which was highlighted by the company as the reason why the iPod line can still deliver somewhat stable revenues during Apple’s most recent earnings conference.

The iPhone 5 got us thinking though. Apple rumors have been very accurate lately, but it seems more likely that Apple will just redesign the iPhone 4, which may be feasible until January 2011 and a subsequent release. An entirely phone, which would also spark a discussion of a new iOS may be a bit optimistic.

There are some now statistics out that indicate an extremely high product loyalty among iPhone users as well as impressive web usage that is most likely fueled by the iPhone 4.

Net Applications found that 0.70% of all web browsing now originates from iPhones. That may not sound much, but that is close to the web traffic posted by Linux systems, which is now at 0.93%, according to the market research firm. Mac OS X 10.5’s share, by the way, is at 1.82% and Mac OS X 10.6 stands at 2.48%, which shows that 0.70% from a smart phone is a big deal: The iPhone has gained 0.11 points in July alone, which was largest single-month usage gain ever. Android, by the way is estimated at a total web usage share of 0.18%.

Nielsen has released some charts that highlight the user loyalty of the iPhone. 89% of iPhone users intend to buy another iPhone, while 6% say they want to switch to Android and 2% say they are looking for a Blackberry. 71% of Android users say they want another Android phone, but 21% want an iPhone next. 29% of Blackberry owners are likely to switch to an iPhone and 21% to an Android phone.

Android seems to be gaining market momentum especially in the U.S. Nielsen said that 27% of new smartphone acquisitions went to Android in the second quarter of the year and only 23% to the iPhone.

Blackhat has started and not surprisingly, there is quite a bit of information coming out of Las Vegas that relates to the iPhone. Lookout revealed some results from its App Genome project, which analyzed about 300,000 apps that are available for the iPhone and Android. Sometimes you get what you pay for and that may be true in the case of iPhone apps as well, in a rather negative way.

Lookout said that one third of free applications for the iPhone can potentially access a user’s location. 14% can access a user’s contacts and 23 of iPhone apps contain third party code. According to the company, new vulnerabilities will be unveiled at Blackhat, including mobile data leakage, which, however, seems to affect Android more than the iPhone.

Lookout noted that App developers need to “be more aware of best practices for accessing, transmitting and storing users’ personal data. In addition, consumers need to be aware of the permissions that mobile applications request and how that personal data is being used in the application.“

Sounds reasonable to us. Given its exposure, the iPhone has become a very attractive target platform for malicious intent. And boy, opening up the platform to all apps, whether they are App Store certified or not, may create an entirely different dimension of software threats.

Way back when, when everyone was still complaining about Apple’s lack of support for (3rd party) multitasking, there was a simple solution put in place. This solution was known as push notifications.

Push notifications solved many of the issues associated with background processing.  For example, when quitting the AIM application, the server could keep you logged in and send you a push notification when a new message arrived.  You could then tap on a View button that would launch the app.

This solution is great and all, but it still requires that you have an active internet connection.  As of iOS4, Apple has introduced a new type of notification that can be scheduled to fire within the device itself.  It requires no complicated server programming, or additional configuration with iTunes.  I am talking about Local Notifications.

Local notifications can be scheduled on the user’s iDevice to fire at any given time; you can even set them to be recurring.  Today, we will explore these notifications and I will provide you with a simple example of how to schedule, view, and handle local notifications.  Here is a quick screenshot of the project that we are going to create (note I am using the iPhone 4  simulator).

The project will allow a user to schedule a location notification to fire off at a given date.  Using the text field, they are also able to specify some text for the notification.  The table view below displays a list of all of the currently scheduled location notifications within the application.

So, by now (if you are an avid iCodeBlog reader), you are already a killer iPhone dev and I can rush through the stuff that is not related to the notifications.  I will try to provide links to tutorials about sections that I rush through as well.

1. Create a View-Based Application

We will be using this as our starting point.  Check out this tutorial if you are unfamiliar with doing this.  Name the project Notifier.

2. Create All Properties and Dummy IBActions

This is usually a good first step when tackling an application like this.  Let’s get everything set up in the .h and .m files so we only have to visit Interface Builder Once.  Here is what our NotifierViewController.h file looks like.

@interface NotifierViewController : UIViewController<UITableViewDelegate,UITableViewDataSource> {
	IBOutlet UITableView *tableview;
	IBOutlet UIDatePicker *datePicker;
	IBOutlet UITextField *eventText;
}
 
@property (nonatomic, retain) IBOutlet UITableView *tableview;
@property (nonatomic, retain) IBOutlet UIDatePicker *datePicker;
@property (nonatomic, retain) IBOutlet UITextField *eventText;
 
- (IBAction) scheduleAlarm:(id) sender;
 
@end

Seems clear enough.  We have 3 UI elements that we care about and one action.  One thing to note is, your class should implement the UITableViewDelegate and UITableViewDataSource protocols.  This is because we will be displaying a tableview containing all of the scheduled alarms.

Now, do all of the necessary steps in your .m file.  This includes memory management for the IBOutlets and creating a dummy method for the scheduleAlarm IBAction.  Your .m file should look something like this. Note: I have omitted import statements because my syntax highlighter wasn’t digging them.

@implementation NotifierViewController
 
@synthesize datePicker,tableview, eventText;
 
- (IBAction) scheduleAlarm:(id) sender {
 
}
 
- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning];
}
 
- (void)viewDidUnload {
	datePicker = nil;
	tableview = nil;
	eventText = nil;
}
 
- (void)dealloc {
    [super dealloc];
}
 
@end

Now it’s time to build our interface.  Open Interface builder and construct an interface like this.

If you want my super sweet green button image, here it is:

After creating the interface, make sure you hook up all of the UI components to their corresponding IBOutlets and hook up the touchUpInside: method of the button the your scheduleAlarm: IBAction.  For more info on hooking up IBOutlets, check out this tutorial.

3. Implement UITableViewDelegate and UITableViewDataSource Delegate methods to List Currently Scheduled Local Notifications

It may seem weird to implement the code to display the notifications before the code that creates them, however I like this approach better.  This way, once we schedule the notifications, they automagically appear in our table.  Add the following code to your .m file.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    // We only have one section
    return 1;
}
 
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    // Return the number of notifications
    return [[[UIApplication sharedApplication] scheduledLocalNotifications] count];
}
 
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
    static NSString *CellIdentifier = @"Cell";
 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:CellIdentifier] autorelease];
    }
 
    // Get list of local notifications
    NSArray *notificationArray = [[UIApplication sharedApplication] scheduledLocalNotifications];
    UILocalNotification *notif = [notificationArray objectAtIndex:indexPath.row];
 
    // Display notification info
    [cell.textLabel setText:notif.alertBody];
    [cell.detailTextLabel setText:[notif.fireDate description]];
 
    return cell;
}

OK, finally some “real” code.  Most of this code should seem pretty straight forward.  If not, check out this tutorial on UITableViews.

So, the new code here is dealing with retrieving a list of scheduled notifications.  Calling the scheduledLocalNotifications method of UIApplication will return an NSArray of all notifications scheduled by the current app.  We just index into this array and grab each notification.

Finally, we are displaying the alertBody (text that displays when the notification fires) and the fireDate (date and time when the notification will display) in the tableview cell.

4. Scheduling Notifications

And now for the moment you’ve been waiting for… OK, probably not, but definitely the most exciting (least boring) part of this tutorial.  Let’s implement that scheduleAlarm: IBAction that you framed out earlier.  Update your .m file to contain the following code.

- (IBAction) scheduleAlarm:(id) sender {
    [eventText resignFirstResponder];
 
    NSCalendar *calendar = [NSCalendar autoupdatingCurrentCalendar];
 
    // Get the current date
    NSDate *pickerDate = [self.datePicker date];
 
    // Break the date up into components
    NSDateComponents *dateComponents = [calendar components:( NSYearCalendarUnit | NSMonthCalendarUnit |  NSDayCalendarUnit )
												   fromDate:pickerDate];
    NSDateComponents *timeComponents = [calendar components:( NSHourCalendarUnit | NSMinuteCalendarUnit | NSSecondCalendarUnit )
												   fromDate:pickerDate];
    // Set up the fire time
    NSDateComponents *dateComps = [[NSDateComponents alloc] init];
    [dateComps setDay:[dateComponents day]];
    [dateComps setMonth:[dateComponents month]];
    [dateComps setYear:[dateComponents year]];
    [dateComps setHour:[timeComponents hour]];
	// Notification will fire in one minute
    [dateComps setMinute:[timeComponents minute]];
	[dateComps setSecond:[timeComponents second]];
    NSDate *itemDate = [calendar dateFromComponents:dateComps];
    [dateComps release];
 
    UILocalNotification *localNotif = [[UILocalNotification alloc] init];
    if (localNotif == nil)
        return;
    localNotif.fireDate = itemDate;
    localNotif.timeZone = [NSTimeZone defaultTimeZone];
 
	// Notification details
    localNotif.alertBody = [eventText text];
	// Set the action button
    localNotif.alertAction = @"View";
 
    localNotif.soundName = UILocalNotificationDefaultSoundName;
    localNotif.applicationIconBadgeNumber = 1;
 
	// Specify custom data for the notification
    NSDictionary *infoDict = [NSDictionary dictionaryWithObject:@"someValue" forKey:@"someKey"];
    localNotif.userInfo = infoDict;
 
	// Schedule the notification
    [[UIApplication sharedApplication] scheduleLocalNotification:localNotif];
    [localNotif release];
 
	[self.tableview reloadData];
}

So, most of the explanation is in the comments.  I’ll talk you through some of the less obvious stuff.  The first tricky area is dealing with the NSCalendar.  We just use the NSCalendar object to break up the date into components.  Note: This demo does not require that we break the date up into components.  You could have just as easily fed the date from the date picker into the notification fireDate.  The reason that I’m showing you how to break it down is, you may have some sort of custom date logic to work with and this makes things much easier in the future.

Another important bit of code is where we set the alertBody or the notification.  In this example we set it to the text that the user entered into the text field.  You can set this to whatever you like.

The other thing I want to mention is the infoDict in the code.  This dictionary is your chance to associate some additional information with the alert.  For example, if you are using this alert in a game like We Rule to notify you when a crop is ready.  You might want to set a key and value that contains the id of the crop that has completed.  For now, we just set some arbitrary values and you can ignore them if you like.

After actually scheduling the notification, we just reload the tableview to get it to display immediately.

5. Handling Notifications After They Fire

The last piece of this puzzle is determining what to do when a notification fires.  Fortunately, this step is very easy and handled inside of the appDelegate.  When a notification fires, there are one of two situations. 1. The app is running and 2. The app is not running (or running in the “background”) .

Open up your app delegate .m file and add the following code.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    
 
    // Override point for customization after application launch.
 
    // Add the view controller's view to the window and display.
    [window addSubview:viewController.view];
    [window makeKeyAndVisible];
 
    application.applicationIconBadgeNumber = 0;
 
    // Handle launching from a notification
    UILocalNotification *localNotif =
    [launchOptions objectForKey:UIApplicationLaunchOptionsLocalNotificationKey];
    if (localNotif) {
        NSLog(@"Recieved Notification %@",localNotif);
    }
 
    return YES;
}
 
- (void)application:(UIApplication *)app didReceiveLocalNotification:(UILocalNotification *)notif {
    // Handle the notificaton when the app is running
    NSLog(@"Recieved Notification %@",notif);
}

The first thing we see here is the application badge number is getting set to 0.  Whenever a notification fires, it will increase the badge count on the application.  Next, we handle the case when the application launches from a notification.   This happens when the user presses the view button on the notification.  For now, we just NSLog the data, but you should handle the notification how you see fit for your app.

Finally, we implement the didReceiveLocalNotification method.  This method is required if you want to handle notifications at all in your app.  You will see this method fire when the app is running and you receive a local notification.  When the app is running, you will not see the UIAlertView show up with the notification data.

And there you have it!  The complete lifecycle of a local notification.  You may download the source for this tutorial below.  If you have any questions, feel free to post them in the comments section or write them to me on Twitter.

Notifier Source Code

]]> http://icodeblog.com/2010/07/29/iphone-programming-tutorial-local-notifications/feed/ 30 http://icodeblog.com/2010/07/26/jailbreaking-iads-t-mobile-and-you/ http://icodeblog.com/2010/07/26/jailbreaking-iads-t-mobile-and-you/#comments Mon, 26 Jul 2010 19:53:01 +0000 wolfgang http://icodeblog.com/?p=2160 It may be a bit tough to keep track with Apple today, even at the accelerated pace we are used to. However, there have been a few interesting bits of information that we think you should be aware of and that surely impact your apps today and in the future. T-Mobile may be announcing its iPhone this week, iAds may be the income source you should be relying on and then there is the fact the U.S. law has now legalized the jailbreaking of smartphones under certain circumstances.]]>

It may be a bit tough to keep track with Apple today, even at the accelerated pace we are used to. However, there have been a few interesting bits of information that we think you should be aware of and that surely impact your apps today and in the future. T-Mobile may be announcing its iPhone this week, iAds may be the income source you should be relying on and then there is the fact the U.S. law has now legalized the jailbreaking of smartphones under certain circumstances.

The new T-Mobile rumor comes via Pocket-lint. Again, a reliable source disclosed that the T-Mobile iPhone will be a reality on July 30. Why July 30? Because that is the day Apple plans to expand the iPhone 4’s availability to 17 more countries and T-Mobile may just fit into that announcement. There was no information on pricing.

A change to the DMCA in the U.S. Code could get you thinking today. There are six scenarios in which consumers are now explicitly allowed to circumvent access controls to digital content, which is generally interpreted as the government’s ok to jailbreaking your iPhone and “liberating” other phones as well. Our conclusion is that the new addition basically opens the door to jailbreaking has many implications that may affect you even if you ignore this new law and stay with Apple’s guidelines.

Circumventing jailbreak blockers is now legally permitted through “Computer programs that enable wireless telephone handsets to execute software applications, where circumvention is accomplished for the sole purpose of enabling interoperability of such applications, when they have been lawfully obtained, with computer programs on the telephone handset.”

As in so many cases, this new law can be interpreted and most certainly will be bent left and right. It is important to see that jailbreaking is only legal if a user tries to run an application that is otherwise blocked – unauthorized apps that are not sold through the App Store. Breaking the software to run the phone on another network is not covered per se. That indicates that Apple will not change its warranty guidelines and they warranty will be void if jailbreaking occurs.

The law does not require Apple to explicitly allow jailbreaking and remove jailbreaking hurdles. Apple simply has to tolerate the ongoing jailbreaking sport and consumers who actually jailbreak their devices to run unauthorized devices. The code change makes it lawful to circumvent any controls that are designed to block jailbreaking. That’s it.

Apple’s major concern of such a law is that potentially unsafe applications can now be run on iPhones and affect other applications as well. The tight control Apple has over the app environment is somewhat impaired and developers will have to recognize that potentially malicious applications can affect all other applications on an iPhone as well. Protecting your app may be evolving as a new topic we should be thinking about more seriously.

On the other side, outside sales open new opportunities for those who believe it is economically beneficial to sell apps through other channels than the App Store. However, several sources have raised the general earnings potential through app stores anyway and other income sources may be something you really should be thinking about. Forrester analyst Thomas Husson wrote earlier today that Apple has made just $429 million in revenue from the App Store so far and that the bottom line isn’t exactly significant to Apple. Husson says that it is likely that “a significant number of independent developers have not recouped their investments via the current revenue-sharing model. “ Also, Husson says that there may be very limited interest from consumers to pay for apps.

The analyst believes that App Stores (other than Apple) will have to change to make their service more beneficial to all participants. He said that stores need to be more explicit about the addressable audience, create a viable business model for third parties, provide marketing and merchandising tools, offer a wide choice of payment and pricing options, show a local content catalog and look at other sources of inspiration – and not just Apple. So, if Apple is not the entire solution, there may be an opportunity now for other stores that carry “unauthorized” apps. If they are able to address current shortcomings, we may just see a new generation of App Stores developing in the very near future.

So we know that the iPad is often criticized as a device that tries to be everything to everyone, but does not excel at any particular discipline. Amazon’s Kindle comes up as an example very often, in which the Kindle is described as the better specialized ebook reader as it has the better screen for reading and better battery life. However, we are also seeing first signs of a new development in ebooks where ebooks turn into multimedia apps that simply can’t run on a Kindle.

Michael Wolf has recently written a great article on this topic for GigaOm Pro (subscription required), and sheds light on what he calls enhanced ebooks. Wolf believes that enhanced ebooks are just developing with all the disadvantages that come along with such a trend – such as inconsistent apps for different platforms, but it is easy to see that, if he is right, that the iPad may be much better positioned for media-rich ebooks than the Amazon Kindle.

That trend has lots of implications for developers, which may suddenly be able to go into a business that was previously reserved for printing services, but offer new types of applications that, for example, create ebook platforms and allow content creators to easily publish media rich magazines, newsletters or ebooks. The market opportunity is substantial, as Amazon announced this week that it is now selling more ebooks than hardcover versions.

Wolf believes that enhanced ebooks may result “in a whole new digital book industry, much like has been seen in the digital video and music industries.” He sees the iPad as a key platform as this trend and consumer perception will evolve. “The media-consumption friendliness of the iPad is a natural choice for authors looking to create a multimedia-laden e-book,” he wrote.

Apple will begin selling the iPad in 9 more countries on Friday. Austria, Belgium, Hong Kong, Ireland, Luxembourg, Mexico, Netherlands, New Zealand and Singapore will be added to the existing base, as Apple has been able to ramp its production to support new geographies.

However, “support” is somewhat relative as market researchers and analysts believe that Apple can still not meet actual demand and that iPad sales are limited by production capacity and not demand. iSuppli today raised its unit forecast by 81% to 12.9 million units for 2010. Next year, Apple may sell 36.5 million iPads and in 2012 50.6 million. If iSuppli is correct than Apple may sell 100 million iPads in less than three years, which makes it an interesting app platform, perhaps even more interesting than the iPhone for some.

“The iPad is shaping up to be the ‘Tickle Me Elmo’ of the 2010 holiday season, with product demand expected to vastly exceed available supply,” said Rhoda Alexander, director of monitor research for iSuppli.

For 2010, Apple is estimated to hold an 84% market share in tablet PCs and continue to dominate the segment at least until 2012. Competition may be insignificant until 2011 when other players, including HP, will have some products to show. iSuppli believes that Apple cannot sit back and just enjoy the success, but actually think about product improvements for next year. Likely additional changes will embrace an internal camera and expansion of the product line, potentially including additional screen sizes, the company said.

Apple rivals, on the other side, will have to focus less on the hardware but relate more to the suite of applications that can be paired with the hardware.

I may be speculating here, but I feel that this was not the last adjusted iPad forecast for the year.

With all the hoopla surrounding the iPhone antenna issues, it’s easy to imagine that Apple may be losing some buyers to Android. There is enough confusion out there to suggest that a different smartphone may be a better smartphone right now.

However, the antenna issue has not really big impact on prospective buyers that are new to Apple, but it may have an impact on iPhone upgrades, which should make you think twice about iOS 4. IDC has published brief results of a survey that asked people whether they are still interested in buying an iPhone 4. 74% of those who wanted to buy an iPhone before have not changed their mind. However, 66% of those who own an iPhone already said they are delaying an upgrade to the iPhone 4. IDC did not break out numbers of those iPhone owners and which iPhones they own.

Of course, those numbers are to be taken with a grain of salt as purchase intentions do not really relate to actual behavior and intentions can change in an instant. However, the numbers may reflect the current mood in the market, which we would describe as cautious. IDC noted that the actual impact of the antenna issues and the effect of Apple’s response to give out free bumpers will only reveal itself over the next few months. That said, Steve Jobs said that more than 3 million iPhones have been sold already.

Wired will be running an article in its upcoming August issue that will shed some light on the rather difficult relationship between Apple and AT&T. While it is always difficult to determine how accurate such reports are, the article promises to provide background information why AT&T seems to be falling of what the iPhone really would need.

Apparently, Apple is not as happy with AT&T as it is publicly stated by the company. According to the article Jobs considered dropping AT&T “more than a dozen times”. It isn’t difficult to figure out what the differences between the two companies really are – it comes down to data capability and affordability. For example, Apple wanted tethering to be included in the data plan, AT&T wanted extra money – which makes sense, as AT&T’s cellular network has been brought down to its knees due heavy data usage and extra charges would create a barrier for additional data use (and deliver extra revenue, of course.)

We can only imagine how much the two are arguing over Facetime and its availability on the 3G network.

There is also some information on the never ending rumors of a Verizon iPhone. The article states that Apple considered switching to Verizon several times, but concluded that the different chip sizes and the tight iPhone design would require Apple to create a CDMA iPhone from the ground up. The article isn’t out yet, but it is worth the read when published.

ChangeWave has released interesting survey findings that indicate sharply rising demand for Apple’s iPhone over the next quarter.  The result contradicts some expectations that Apple may be gambling away its customer trust by ignoring the iPhone reception issues, but then we do know that the company may be addressing some questions in an upcoming press conference and an iOS update.

The survey concluded that the iPhone leaves its users far more satisfied than any other phone: RIM with 30%. Especially Blackberrys seem to have lost their cool factor and Research in Motion has to think about ways to regain traction. The same goes for Motorola, which has lost consumer interest over the past quarter. Onbly 6% (down from  14%) of smartphone buyers are looking into a Blackberry and only 9% (down from16%)  into a Motorola device. Interest in the iPhone has jumped from 31% to 52%, while HTC’s Android devices have also shown more traction: 19% of respondents said they were looking into an Android HTC phones (up from 12%).

According to ChangeWave, “the momentum for Apple and HTC is occurring at the expense of other smart phone manufacturers – Motorola and Research in Motion in particular. […] The market situation for RIM appears far more problematic, at least short term. RIM’s customer satisfaction ratings have plummeted for the past 7 quarters, and planned buying among consumers is at the lowest levels ever recorded for RIM in a ChangeWave survey.”

BMW has been pretty quick to take advantage of iOS 4 and enable the new iPod Out new feature that was first described in April when developers noted an extended “iPod Accessory Protocol”.

BMW said it is using the software update to generate an iPod-like menu on the center dash display of BMWs and Minis. Users can control the playback of media from the car’s own controls rather than using a touchscreen. The update also integrates new in-car features such as custom playlists as well as Genius playlists.

There was no information which cars will be offering the new feature and when it could be available. BMW simply says that the feature will be coming to future cars. However, iPod Out will be a key feature of the Mini Connected system, which is expected to make its debut in next year.

A range of BMW models are due for a refresh. The new 3 series, 6 series and the refresh of the 7 series are more than likely to offer iPod Out right away.

That may sound like a rather silly question and you may answer that it is a tablet, of course. But, if you think about it, the iPad can be many things to many people, depending on why it is purposed. And given the fact that Apple needs to carve out a market for it, it is likely that many buyers are using the iPad to replace something else. And that is the core of the question: What is the iPad – and what is it to most people? If you know the answer, you may have a good idea what apps you should be developing to target iPad users.

So take a guess: Is it the Internet browsing device that was demonstrated by Steve Jobs? Or is it a gaming device?

It turns out that a market research firm, Resolve, has looked at exactly that question and has come up with some interesting numbers.

49% of people in the survey, and owners of an iPad, said that, because of the iPad, they would not buy an e-reader as a result. 38% said they would not buy another portable gaming device and 32% said they would not buy a netbook as a result. Conceivably, most people see in the iPad a great e-reader and portable gaming device. However, 60% said that the best mobile gaming device would be a “portable gaming device” and only 23% pointed to the iPad. 8% mentioned that a smartphone offers the most enjoyable mobile gaming experience. The implication seems to be clear: Despite the fact that Amazon’s Kindle is generally considered to be the better e-reader, the iPad is invading its turf and the Kindle may need to drop further in price.

Resolve also looked into the purchase decisions – and what made people buy the iPad. 56% of buyers are looking for entertainment and 42% simply think the iPad is “cool”. The iPad is generally see as an “expensive toy” and a “breakthrough technology” device. Reasons for not buying the iPad currently include its price and the fact that people simply do not know what to do with it. 37% of iPad buyers do not own any other Apple products, Resolve said. 49% own an iPod, 24% an iPhone and 16% a Macbook.

Books and games appear to be the biggest opportunities on the iPad, if Resolve is correct.

So we have heard about Apple’s ginormous advertising deals for iAd, but it seems that Apple’s deals reach through to developers as well. One developer, Jason Ting, said that his LED flashlight app (LED Light for iPhone 4), which is offered as an ad-supported free version, turned in $1372.20 of advertising revenue in one day.

That revenue was based on 9000 downloads, 9300 ad impressions and a click-through rate of 11.8%. The eCPM rate came in at close to $150, which is about 100 times higher than what other mobile deals currently pay. And if you compare the deal against standard eCPM models, Apple’s pay is up to 300 times higher. Of course, Ting appears to be an extreme example, as we have heard other reports with much lower eCPM rates as well. And Ting’s revenue still includes Apple’s 40% cut.

Another developer, Kenneth Ballenegger, said that his eCPM was somewhere between $10 and $15. He also noted that iAd’s fill rate is at just 10% and the ad refresh rate is much lower than that of other ad networks and he, in fact, said that he expects iAd eCPM rates of just over $1 in the long run. In the end, the fill rate seems to be what is the biggest concern out there and it’s so low that, for many developers – those with extremely high ad views – it just does not replace Google yet. However, iAd just launched and like other networks it needs some time to ramp up. So let’s be patient.

We should be realistic about the eCPM rates. Of course, there’s a novelty to iAds and that certainly benefits developers right now. Eventually, the eCPM rate will fall, but we would expect the numbers to remain higher than on the desktop. You can run iAds and use other networks such as Google as a fallback option.

#import <UIKit/UIKit.h>;
#import <AssetsLibrary/AssetsLibrary.h>;

@interface MyImagePickerViewController : UIViewController {
 
	IBOutlet UITableView *tableview;
	IBOutlet UIActivityIndicatorView *activity;
 
	NSMutableArray *assets;
}
 
@property (nonatomic, retain) IBOutlet UITableView *tableview;
@property (nonatomic, retain) IBOutlet UIActivityIndicatorView *activity;
 
@end

We are going be using the assets array here to hold the assets that we are going to pull using the AssetsLibrary Framework.

Now open up MyImagePickerViewController.xib and drag in a UITableView and a UIActivityIndicatorView. With these in place connect them to the IBOutlets you created for this class. Also make sure to connect the UITableViewDataSource and UITableViewDelegate to the MyImagePickerViewController as well. With that done we can start to use the AssetsLibrary Framework.

Using the Asset Library

Now we are going to use our AssetsLibrary framework. This will be done within the viewDidLoad method of your MyImagePickerViewController.m. Put the following code in there.

1 - (void)viewDidLoad {
2
3    [super viewDidLoad];
4    [activity startAnimating];
5
6    void (^assetEnumerator)(struct ALAsset *, NSUInteger, BOOL *) = ^(ALAsset *result, NSUInteger index, BOOL *stop) {
7	if(result != NULL) {
8		NSLog(@"See Asset: %@", result);
9		[assets addObject:result];
10
11	}
12    };
13
14    void (^assetGroupEnumerator)(struct ALAssetsGroup *, BOOL *) =  ^(ALAssetsGroup *group, BOOL *stop) {
15	if(group != nil) {
16		[group enumerateAssetsUsingBlock:assetEnumerator];
17	}
18
19
20	[self.tableView reloadData];
21	[self.activity stopAnimating];
22	[self.activity setHidden:YES];
23    };
24
25    assets = [[NSMutableArray alloc] init];
26    library = [[ALAssetsLibrary alloc] init];
27    [library enumerateGroupsWithTypes:ALAssetsGroupAlbum
28					   usingBlock:assetGroupEnumerator
29					 failureBlock: ^(NSError *error) {
30						 NSLog(@"Failure");
31					 }];
32 }

We are going to be going though this code line by line. On line 4, we start animating our activity indicator. I will explain why we have to do that a little bit later. Lines 6 – 23 are the lines that will  declare the two blocks that we will use to fill our tableview with pictures. We are going to declare two blocks to use as parameters to methods within a ALAssetLibrary object and a ALAssetGroup object. The first method call we will make will be on our ALAssetLibrary object. So for the moment lets skip passed the block declarations and look at line 25. On line 25 we instantiate our NSMutableArray to hold the ALAssets that we will pull out from the AssetsLibrary. On line 26 we will create our ALAssetsLibrary object. We will call a single method on this object to loop through all of the assets in a library. The method is:

– enumerateGroupsWithTypes:usingBlock:failureBlock:

This method takes in 3 parameters. An ALAssetGroup type, a block to be performed on each group and a block to be performed on failure. Lets talk about block syntax. A block is a native Objective C object. It is a subclass of NSObject. With that said it is also an Objective C method. An objective C method is composed of three things. A return type, a parameter list and a piece of code to be executed. We are going to pass the assetsGroupEnumerator block object that declare on line 14 into this method. Lets take a look at how the block is declared.

You begin by specifying a return type for the block. Void in this case. Next you enclose a name for the block which is proceeded by a carrot ^ character. This is the special character Apple has decided on to denote blocks. You begin block names with blocks as well as the actual declaration of what a block is. This name is wrapped in parenthesis. This is followed by the parameter list that the block will accept. In this case it is a ALAssetsGroup object and a Boolean indicating whether to stop. Now I did not come up with these parameters by myself. Since I will be passing this block into an ASAssetLibrary the documentation will tell us what will be passed into the block. ALAssetsLibrary objects documentation can be seen here. With that all said, lets take a look at the code that will actually compose this block. Starting on line 15 we will make sure that we are seeing a valid group. If the ALAssetsGroup object that we are passed is valid then we will call another enumeration on the group which will enumerate through assets. This enumeration method also requires a block. We declared this block above. This block is called assetEnumerator. Once again we retrieved the parameters list from the documentation of the object asking for, in this case an ALAssetsGroup.

For this block, which begins on line 6, the block is passed an ALAsset object, an index and a stopping condition boolean. Within the code of the block we will ensure that the returned ALAsset is valid and if it is we will add it to our array which will hold all of our assets. With this block declared we pass it into the call to our ALAssetsLibrary object on line 16.  Once every group has been enumerated and our array is filled with all of our ALAssets we will tell the tableview to reload its data and get rid of our UIActivityIndicatorView.

With all of this done all that remains if filling in the required UITableViewDataSource methods. The tableview will be filled with the assets we collected. ALAsset objects are cool in that they include a method called -thumbnail which returns a CGImageRef to a thumbnail we will use. I won’t explain the development of these methods any further since they are pretty straight forward.

// Customize the number of sections in the table view.
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return 1;
}
 
// Customize the number of rows in the table view.
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return [assets count];
}
 
// Customize the appearance of table view cells.
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
 
    static NSString *CellIdentifier = @"Cell";
 
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
    }
 
	ALAsset *asset = [assets objectAtIndex:indexPath.row];
	[cell.imageView setImage:[UIImage imageWithCGImage:[asset thumbnail]]];
	[cell.textLabel setText:[NSString stringWithFormat:@"Photo %d", indexPath.row+1]];
 
    return cell;
}

Most of us may scratching their heads over the question how to get some apps into the App Store in the first place. Mozilla, for example, is still hoping that its Home app is making the cut. Once you are in the store, it appears it’s a fair game and you can focus on marketing your app. But you can also do what  Thuat Nguyen has done and get booted from the store altogether. And if you heard about Nguyen already then you might be upset, but, realistically, it was just a matter of time until we would see some fraudulent exploit.

What happened is that Nguyen was able to occupy 42 of the top 50 sales positions in the App Store’s “book” category using bogus apps. Interestingly, when Nguyen’s apps appeared, there was also a spike in complaints of iTunes accounts being hacked and being overcharged. Apparently “only” a few hundred accounts were affected until Apple booted Nguyen, which is the good news. The bad news is, of course that the exploit happened and that it may have affected the credibility of tens of thousands of other developers.

Courtesy of Engadget, Apple has posted a statement, which reads:

The developer Thuat Nguyen and his apps were removed from the App Store for violating the developer Program License Agreement, including fraudulent purchase patterns.

Developers do not receive any iTunes confidential customer data when an app is downloaded.

If your credit card or iTunes password is stolen and used on iTunes we recommend that you contact your financial institution and inquire about canceling the card and issuing a chargeback for any unauthorized transactions. We also recommend that you change your iTunes account password immediately. For more information on best practices for password security visit http://www.apple.com/support/itunes.

The App Store and Apple’s tight grip on what is published and what not through, let’s be honest, a walled garden approach, has always promoted the idea of high quality applications and a sense of security that, for example, Google just can’t provide with Android. But it should be a wake-up call for app buyers as well as developers that the App Store can be exploited in way it was not designed for. This case may have been just a shot in front of the bow and the damage could have been worse.

Of course, Nguyen’s approach was a sure bet to get booted from the App Store and I’d be surprised if that was already everything we have heard about him and Apple. The App Store has been and still is a relatively safe environment to make purchase and I doubt Apple will risk this perception. But, personally, I would wish Apple would be a bit more vocal in its support for developers in this situation. And more vocal to calm potential concerns of consumers. Just silencing the topic does not always work.

A version of the good old neighborhood watch may be the best protection of the community against such fraudulent exploits. However, even on an individual level, you should be making sure that your reputation is not affected by such exploits. More and more consumers may be trying to find ways to determine whether an app is real or not and you should make it as easy as possible for them to figure that out. Make sure you have a functioning web site and an active support section. Make sure you can be contacted and maintain a public persona, perhaps through a Facebook page. Public exposure creates confidence and you can use this way to earn trust.

Vision Mobile has just posted one of the more impressive research reports and surveys that focus on mobile application development. This new report, called Mobile Developer Economics 2010: The migration of developer mindshare examines facts and emotions that guide developers these days in their efforts to make a living from app development. The survey included 400 developers across 8 platforms (iOS (iPhone), Android, Symbian, BlackBerry, Java ME, Windows Phone, Flash Lite, and mobile web.)

The 57 pages are easily considered a must read if you are interested in competitive app development, publishing and marketing in any way, as the data lets you keep an eye on your colleagues and rivals and possibly reveal one or the other surprise.

Vision Mobile’s survey found that Android is carrying the mind share right now, as 60% of its respondents said that they recently developed for that platform. iOS follows in second place and then, … well, then there is really nothing after that as far as mindshare migration is concerned as those two platforms are described as leading the “industrial revolution era” of the mobile app development space:

From the report: “The next five years will completely remap the mobile industry landscape. RIM and Apple, two verticalised companies, move into the top five, displacing the incumbents, leaving one Finnish and two Korean companies in pole position. The operating system landscape will consolidate into two tiers; the top-end open to iconic products dominated by Apple and followed by the iPhone clones powered by Android; and the feature-phone market where licensable operating systems (Android and BREW) will finally allow handset OEMs to move away from legacy RTOS platforms. Google’s Android will also power a diverse range of new form factors, from picture frames to car dashboards, offering for the first time a simplified platform from which to achieve convergent interconnected services. In this age of Industrial Revolution, mobile developers will be responsible for most of the innovation on mobile devices, and can act independently from the mobile industry powers-that-be – OEMs or network operators – to get their applications to market. In this age, developers have both power and choice.”

The lion’s share of the report is dedicated to Android and iOS and if you have ever had competitive questions you might find some answers here.

Among the data that captured my interest was:

- 75% of app developer choose their preferred platform by evaluating the market penetration
- 50% of Windows phone developers have an iPhone
- A standalone developer can expect to sell somewhere between 1000-2000 copies of a $1.99 app
- 5% of iPhone developers said there apps had “very good” revenues
- 27% of iPhone developers said their revenues are as projected
- 24% of iPhone developers reported poor revenues
- The App Store has three times more apps than Android Market, 30 times the apps of Symbian and more than 40 times the apps of Flash Lite.
- 21% of developers say they do not get any support, only ten 10% report very good support

You can discuss why Android carries the mind share and I would have to say that it isn’t entirely clear to me, based on this report. The respondents did criticize Android quite a bit, for example that its App Store model that has virtually no flood gates, makes it harder for high-quality apps to compete. Developers complained about the lack of support, which they can’t even get for money, and they highlighted the lack of documentation of open source platforms, which impacts their development.

You can read the entire report here.

AT&T caused some waves recently when it simply canceled its flat fee wireless data plan and replaced with two plans that have caps, which, in some scenarios could get rather expensive for the user. Some analysts, such as Jack Gold from J. Gold Associates, have said that efficient data usage of apps may become a part of future wireless benchmarks.

However, even if those 200 MB and 2 GB caps sound tight, most of us will have to admit that we simply have no idea how much data we actually consume on our smartphones. Common sense would suggest that there are smartphones that promote data usage and there are some that are too clumsy and create a barrier for data usage. The iPhone, with more than 200,000 apps on tap and countless apps that heavily rely on data, may be among those devices that consume considerable data – which, in fact may have been a reason for AT&T to introduce those new caps just before the introduction of the iPhone 4.

But that does not answer the question how much data we actually consume, of course, and is very much speculation on our part.

Nielsen tried to give some answers by revealing some of the results it got from analyzing 60,000 phone bills. And, as you may imagine, there were some surprises.

What was expected is the fact that increased smartphone data penetration, the availability of more apps and the simple fact that we are getting more comfortable using smartphones results in more data usage. The average monthly data consumption jumped from about 90 MB in January 2009 to about 298 MB in January 2010.

However, Nielsen found that 6% of smartphone users are consuming half of all data. 25% of smartphone users consume less than 1 MB of data. Another 25% do not use any data service, despite the fact that they have signed up for such a plan and pay for it. They use their smartphone only for voice calls and messaging. Nielsen criticized the carriers for this scenario and urged them to do a much better job educating their customers.

More than a third of smartphone users do not subscribe to a data plan at this time. Nielsen said that these users got their smartphones before operators required a data plan.

All these numbers aside, it is somewhat clear that the bandwidth discussion has trickled down from the desktop to the mobile landscape. Data is the new revenue opportunity as voice is commoditized. AT&T is leading the charge, while others with substantial market share may follow soon. Other carriers that have built their business model on a monetary value proposition may have it more difficult to switch to such a model.

In that view, it is interesting to note that, at least for now, AT&T’s new tiered pricing plan may be a good value and not be as expensive as it seems. Nielsen said that 99% of cellphone subscribers are better off with the new model. That is, of course, until applications such as video calling will make it to 3G/4G networks.

Apple will be rolling on its iAd service on Thursday and open up a potentially very lucrative revenue source for application developers as well as another revenue source for itself. It’s a high-rollers market now, but don’t expect mass advertisers to be playing ball just yet.

Recent reports indicated that iAds are commanding huge premiums. The first row of advertisers is reportedly shelling out at least $1 million each for the privilege to get advertising exposure. If you intend to cover channel exclusivity, the price can top $10 million. Apple recently said that it has already sold $60 million in committed ads – which Apple claims is about half of the total committed ad spending for mobile platforms this year. Among the first advertisers are AT&T, Best Buy, Campbell Soup Company, Chanel, Citi, DirecTV, GEICO, GE, JCPenney, Liberty Mutual Group, Nissan, Sears, State Farm, Target, Turner Broadcasting System, Unilever and The Walt Disney Studios.

iAd pricing is the highest in the mobile segment, as far as we know. Banners get $10 for 1000 hits, once click gets $2. It is interesting to note that all ads will be targeting the iPhone initially, as iOS 4 will not be available for the iPad until November. AppleInsider recently wrote that most advertisers are still in the early planning stages for their iAd campaigns and that they aren’t ready to roll their ads out just yet. By the end of the year, iAds should have much greater traction.

Some advertising agencies seem to be unhappy about the fact that Apple controls the technical production of iAds itself. According to AdAge, Apple tells advertisers that it takes about 6 – 8 weeks to run an ad after the artwork has been delivered. However, this fact does not seem to turn down many customers.

“Any brand that does it is instantly aligned with Apple,” said Darrell Whitelaw, creative director of mobile shop MIR, which is designing Citi’s iAd, in an interview with AdAge. “It’s instant credibility, instant cool. You’re on the new iPhone 4; it really is the one way you can align yourself with that little Apple logo.”

iAds require iOS 4, which means that the iPad will not get iAds for now. However, AdAge said that it has noticed iPad campaigns being scheduled for November, which would mean that iOS 4 will be coming to the iPad in that time frame.

Google has just released a new version of its Doc Viewer, which enables iPhone users (and developers) to display various file formats right within the browser windows.

The viewer supports Microsoft’s DOC and DOCX formats, as well as DPS, TIFF and PPT. The viewer can be used online at http://docs.google.com/viewer.

However, Google also offers an embedded version. The viewer URLs uses the address path http://docs.google.com/viewer and supports two parameters: url points to the url of the document and embedded enables the embedded mode interface.

A direct link to a PDF file would look like this:

<a href=”http://docs.google.com/viewer?url=http%3A%2F%2Fwww.test.com%2F123.pdf”>Document Test</a>

The embedded version:

<iframe src=”http://docs.google.com/viewer?url=http%3A%2F%2Fwww.test.com%2F123.pdf&embedded=true” width=”600″ height=”780″ style=”border: none;”></iframe>

Earlier today, Apple sent out a note stating that it has sold 1.7 million iPhone 4s during the first three days of its availability. No other Apple launch has moved a similar number of units at launch. The original iPhone needed 74 days to hit 1 million, the 3G S sold 1 million units in 3 days and the iPad sold about 1 million units in a month.

The economics behind the launch are especially interesting. AT&T and other retailers are believed to pay nearly retail price to Apple for each iPhone, while the profit is mainly made via service contracts. At $600 for the cheaper version of the two iPhone variants, Apple’s iPhone 4 has already shifted more than $1 billion in sales in three days. Some estimates claim that Apple will be selling some 2.5 million iPhones until the end of July.

Market research firm iSuppli has already come up with some other numbers in its teardown report. Apparently it costs Apple about $188 to build and assemble each 16 GB iPhone. The most expensive component remains the screen, which is estimated at $28.50. That may be one of Apple’s best profit margins yet: Typically, the margin is somewhere in the 40-50% neighborhood. The iPhone 4 margin is at close to 70%, if the (unofficial) $599 price tag is correct.

If you order an iPhone 4 now, you will have to wait until the end of July, we hear. And those who don’t want to shell out $200 can get discounts or even free phones in a contest wave that is already flooding the Internet. The most creative idea may come from BlendTec, which said it will give one lucky winner an iPhone and prepay a 2-year service contract. In return, you are asked to surrender your old iPhone, which may end up in iSmoke and ascend to YouTube fame.

Consider this scenario. You in wonderland. Your app among 200,000 other apps in one store. Plenty of customers: More than 3 billion downloads confirmed. A great new iPhone with brisk demand. An iPad that is breaking sales records and is already beyond what many analysts had predicted initially. Soon there may be 100 million customers that are directly connected to the App Store as their only resource for software. You may already be thinking about an early retirement. Think again.

Well, never say never. If you have a great app with mass market appeal becoming a millionaire with a few weeks is not out of the question. There are enough success stories out there. But, of course, there are enough apps out there that get hardly any downloads as well.

So, how exactly do you predict the sales of your future iPhone App? I mean, reasonably?

What should you expect?

Do you aim high or do you aim low?

Heck, what should you aim for at all?

Let’s ignore all those fairy tales of mega-sellers that create instant millionaires for as moment. Of course, it takes a great app, a lot of work, marketing and quite a bit of luck to strike it rich. And if you depend on a very successful app right now while you would be screwed otherwise, you may want to look elsewhere. As it turns out, if you aren’t already a big player, betting on a successful iPhone/iPad app may be a bit like gambling. Or like launching a website that promised gazillions of dollars of ad revenues.

On a reasonable level, there has been a recent article that has caught my attention. It takes a much more conservative look (a very conservative look, in fact) at what the average app earns. It could be a bit frustrating to read, but it may help to adjust some expectations.

The BSN article dives deep into publicly available numbers and draws conclusions by using numbers that may not be accurate, which is why we should take them with a grain of salt. The foundation for the calculated revenue is Apple’s publicly disclosed figures of currently $542 million of revenues in the first half of the year. The app average does not sound too bad, but this is, of course, a distorted view since, as so often, 5% of the paid apps are generally believed to account for 95% of the revenues. 200,000 apps and $542 million would mean that the average app author gets $2710 every six months, which is not that great, but then we know that the majority of downloads are free downloads (according to BSN about 85% of downloads are free, while they represent only 27% of the App Stores stock), but a few apps rake in millions while others just a few dollars.

BSN quotes market researchers who believe that the average price paid for an app is somewhere between $1.90 and $2. The average app gets less than 1000 downloads over a 2-year period and if we apply a median number of $1.95, then the media revenue would be about $1950 per app over two years, or $682 per year after Apple’s 30% cut. Building a business on that would be kinda foolish, of course.

But then, this is really a very conservative scenario. If you are enthusiastic about your app, and you have a powerful social network that can help you market your app, or have other resources to get you going, you may very well end up north of that median. BSN also noted that each iPhone/iPad is estimated to generate about 7 paid downloads and 40 free downloads per year. With 100 million outs in the market soon, that is a substantial opportunity. And it is up to you how you take advantage of this opportunity.

Predicting the potential customer base for your application is not that easy. It has become clear that especially the iPad has become a moving target that should be taken seriously. Latest sales numbers are proof that it is worth your while to make sure that you app runs well on both the iPhone and the iPad.

Apple said that 3 million iPads have been sold in 80 days. That works out to about 37,500 iPads every day. While this number is impressive, Apple’s numbers also suggest that iPad sales are climbing beyond the initial sales volume right after launch. As far as we know, it took Apple 28 days to sell the first million of iPads. It took about (we don’t know the exact count) 30 days to sell the second million and apparently about 22 days for the third million.

There was some speculation that overall sales could die down, but it seems that international demand is actually accelerating the demand. There have been some colorful comparisons, as Apple highlighted the “80 days” mark and mentioned that Apple will be making the iPad available to more people around the world. So Apple sold 3 million iPads in the same time Phileas Fogg traveled around the world in Jules Verne’s 1873 novel Around the World in Eighty Days. But in case you are wondering, of course, the iPads solds would not be able to make it “around the world.”  If placed end-to end, the line of iPads would stretch for about 452 miles. Apple will have to sell 165,067,381 iPads to make it once around the globe.

Not surprisingly, Apple’s new estimate has brought updated sales estimates from analysts, which have been somewhere between 5 and 7 million for this year, with the exception of Forrester, which was, as far as we know, the only research firm that indicated a slowdown of iPad sales, as they believe 3.5 million tablets (including the iPad) will be sold this year. Piper Jaffray’s Gene Munster now believes that Apple will sell 7.5 million iPads in 2010, up from a previous estimate of 6.2 million. By the end of 2011, Apple will have sold 16.5 million iPads, Munster said in a research note to his clients.

Given the fact that the sales estimates that most analysts covering the iPad have revised their estimates at least half a dozen times this year already, I wonder where we really will end up by the end of the year?

If you haven’t done so yet (not that we believe you didn’t), it’s a good time now to have a closer look at Apple’s new iOS 4, which was officially rolled out yesterday.

So we have known about it for two months and talked about it a couple times. In numbers, there are 100 new features and access to more than 1500 APIs, with details being provided by Apple on its SDK site.

There is a lot of focus on the new features (Ars Technica has the most thorough first look we have seen so far), but given Apple’s emphasis on iOS 4, the real news may not be so much new APIs or features, such as multitasking, per se. It’s the collective opportunity behind it.

Of course, there will be a race who will have the first apps out that use some of those new features, but it may the app that finds a way to take an intuitive approach to leverage iOS 4 features that will come out on top. It is a comprehensive update that can be overwhelming and clearly needs some thought. Perhaps that was the reason why Apple has given us more than two months to prepare for this release, if you think about it.

It is not particularly difficult to figure that Apple will push this release hard. There is some competition out there and we expect Apple to step up the marketing game even more, which should create new ways to ride in Apple’s tailwind to market your application. Make sure you are ready for this opportunity. It’s a growing market that quickly rewards your creativity and innovation.

We will spending quite a bit of time with iOS4 over the next few weeks, so make sure you check back frequently.

It is no secret anymore that Apple is shattering pre-sales records with the new iPhone. Apparently, more than 600,000 phones have been ordered in just one day. What is much more interesting, are the forecasts just how far this new phone can go. Morgan Stanley’s Katy Huberty thinks Apple may be able to expand its user base to 100 million iPhone owners and users. She believes that about 42 million fourth-generation iPhones could be sold by the end of the year.

We know that Huberty is usually among the more optimistic analysts – especially since her rather controversial iPad sales predictions, but even if she is slightly off, those numbers are huge. Huberty thinks that the iPhone 4 is attractive enough so that Apple can triple its user base within 18 months. That should have some impact on its market share which is currently just above 5% of the entire cell phone market, according to Gartner.

So what does that mean for application developers? Obviously that’s good news as the market expands and iPhone/iPad users are getting more and more used to how those apps of a smartphone or tablet work. However, there is another statistic out by ABI Research, which now says that, by 2015, some 1.2 billion apps will be downloaded (Overall, not just Apple). We are not quite sure where that number exactly comes from, especially since ABI quotes the most recent number of more than 200,000 available iPhone apps and we also know that Apple said earlier this year that more than 3 billion apps have been downloaded within 18 months of the launch of the AppStore.

ABI believes that competition will play a role in available apps and app sales and therefore says that downloads will peak sometime during 2012 and 2013. The market research firm noted that there are many apps that do not provide much value. Neil Strother, practice director at ABI, explained: “When considering the value of mobile apps as marketing tools, planners need to take a step back from all the hoopla and ask themselves, ‘How will those work for my brand? Is it right for me? What is my audience doing? Do I even have a large mobile audience? If so, how do I craft an effective strategy?’”

So yes, while we have a tough time finding a way to back up ABI’s numbers, we do agree that app strategy absolutely matters if you are trying to come up with a successful app.

Hey iCoders. As I posted earlier I recently made an iPad app called TweetMapper. I just put out a new release of the app with a big new feature. The app now has a scrolling timeline of the tweets it is seeing as they come in. In order to make this app I took advantage of the Twitter Stream API that is provided by twitter. This API creates a persistent connection between the Twitter servers and your application. We will essentially start a stream of incoming NSData object to an NSURLConnection that you create querying the stream. We will look into the different search parameters which can be passed into the request, the way in which our code responds to authentication requests from Twitter, and the logic we must use to ensure that the data we have received is a complete XML element and not chopped off. There are three major steps to taking advantage of this in your app.

1. Create an NSURLConnection to request an XML response from the Stream.
2. Create a parameter string for the HTTP Body.
3. Respond to the authentication challenge with user credentials.
4. Append the data as it comes in and when a complete element is received parse the Tweets.

So lets dive in.

Creating the Class

The first thing that we need to do is establish a connection with the Twitter stream. I will not be creating a Twitter client class that can be plugged into any application you choose. You will be able to find the class as a download at the end of the post. We will call the class TwitterStreamClient. Lets first define the header file of the class.

#import
#import "TouchXML.h"
#import "Tweet.h"
 
@interface TwitterClient : NSObject {
 
	NSString *searchString;
	NSString *locationString;
	NSMutableString *holderString;
	id mapController;
	NSURLConnection *connection;
	NSMutableURLRequest *request;
}
 
@property (nonatomic, assign) id mapController;
 
-(void)startStreamingTweets;
-(void)makeMyRequest;
-(void)searchByLocation;
-(void)searchByTerm;
-(void)searchByUser;
-(void)parseXMLString:(NSString*)xmlString;
-(NSString*)locationStringForLongitude:(double)_long Latitude:(double)_lat;
 
@end

You will need to have TouchXML installed for this class to work. You can find installation instructions here. Let move onto the .m file of the TwitterStreamClient. First thing to do is create the initializer. Ours will look like this:

-init {
	if([self = [super init]) {
		holderString = [[NSMutableString alloc] init];
	}
 
	return self;
}

This holder string is what we are going to use to synchronize our incoming NSData from the service. We will see the reason for this in the next step.

Connect to Service

The Twitter stream provides many different parameters for users to pass into their request. You can see the full list here, but we will be focusing on user specific stream, keyword specific stream and location specific stream. We are going to be hardcoding what these will be searching for but in use you can pass in whatever values you like. We will create an NSMutableURLRequest and fill in its HTTP body with the appropriate request. First we will make a method to create the stream request.

-(void)makeMyRequest {
 
	request = [[NSMutableURLRequest alloc] initWithURL:[NSURL URLWithString:@"http://stream.twitter.com/1/statuses/filter.xml"]];
	[request setHTTPMethod:@"POST"];
}

With this done we will create three different methods that can be called. One that bases its search on keywords, another based on users and a final one based on location.

Request by keyword

-(void)searchByTerm {
 
	searchString = @"track=Love,Hate,Want,Need";
 
	NSString *httpBody = searchString;
	[request setHTTPBody:[httpBody dataUsingEncoding:NSUTF8StringEncoding]];
	connection = [[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES];
	[request release];
}

Request by User ID

-(void)searchByUser {
 
	searchString = @"follow=14402149,29089557,807095,19058681";
 
	NSString *httpBody = searchString;
	[request setHTTPBody:[httpBody dataUsingEncoding:NSUTF8StringEncoding]];
	connection = [[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES];
	[request release];
}

The final method will create a location string. The twitter stream requires passing in 4 coordinates, 2 coordinate pairs. This will define the southwest most point and northeast most point. The square that the coordinates define has a maximum of 1 degree length for any side of the defined box. My helper method takes in a longitude and latitude as a center points and creates as large an area as possible around it and returns the 4 coordinates as a string. Paste in the following code to search with center points on Tempe, AZ and New York, NY.

-(NSString*)locationStringForLongitude:(double)_long Latitude:(double)_lat {
 
	NSString *returnString = [NSString stringWithFormat:@"%f,%f,%f,%f",(_long-.5),(_lat-.5),(_long+.5),(_lat+.5)];
 
	return returnString;
}
 
-(void)searchByLocation {
 
	searchString = [NSString stringWithFormat:@"locations=%@,%@",
					  [self locationStringForLongitude:-111.932898 Latitude:33.419265],
					  [self locationStringForLongitude:-74.0 Latitude:40.7]];
 
	NSString *httpBody = searchString;
	[request setHTTPBody:[httpBody dataUsingEncoding:NSUTF8StringEncoding]];
	connection = [[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES];
	[request release];
}

Answering Authentication

The NSURLConnection will connect to the Twitter stream and then Twitter will ask for a username and password for the request. With the NSURLConnection’s delegate set to self we will implement the following method to answer the TwitterRequest.

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
 
	NSURLCredential *cred = [[NSURLCredential alloc] initWithUser:@"USERNAME" password:@"PASSWORD" persistence:NSURLCredentialPersistencePermanent];
	[[challenge sender] useCredential:cred forAuthenticationChallenge:challenge];
	NSLog(@"Received Challenge");
	[cred release];
}

This should satisfy the authentication challenge and the stream should start sending you data.

Receiving Data

Now the stream will start sending you data, it will coming into another NSURLConnection delegate method. The stream will send NSData into this method. The NSData can be parsed into a string and if you print it you will see output like this:

2010-05-21 14:05:17.491 TweetMapper[72280:207] Recieved Data from Stream:
 2010-05-21 14:05:17.919 TweetMapper[72280:207] Recieved Data from Stream: 
  Fri May 21 21:05:17 +0000 2010
  14452520592
  Need some followers yo I jus got this twitter its pretty str8
  <a href="http://mobile.twitter.com" rel="nofollow">Twitter for Android</a>
false
 
  false
 
    144901351
    David Powell
    Ballaholic3223
 
    I'm a chill dude that love to play ball, hang out,  and uhhhh chillax...holla at me and we can be cool
http://a1.twimg.com/profile_images/907668616/VDG61D80_normal
 
false
    1
9ae4e8
000000
0000ff
e0ff92
87bc44
    0
    Mon May 17 16:17:15 +0000 2010
    0

2010-05-21 14:05:23.073 TweetMapper[72280:207] Recieved Data from Stream: e_background_color>
666666
2FC2EF
252429
181A1E
    5
    Fri Aug 01 08:10:36 +0000 2008
    0
    -28800
    Pacific Time (US & Canada)
http://s.twimg.com/a/1274144130/images/themes/theme9/bg.gif
false
 
    false
    false
 
    44
    en
    false

A response from the Twitter stream comes in as XML. An entire XML element that represents a single is a element. The status element seen here took two different calls to the didRecieveData method. Because of this we need to build in logic to recognize when a complete Tweet XML object is received and pass that onto our parsing method. This is what we use the NSMutableSting holderString for. You can see the completed method below.

- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
 
	NSString *dataString = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
 
	[holderString appendString:dataString];
	[dataString release];
 
	if([holderString rangeOfString:@""].location != NSNotFound && [holderString rangeOfString:@""].location != NSNotFound) {
 
		if([holderString rangeOfString:@""].location < [holderString rangeOfString:@""].location) {
			NSRange start = [holderString rangeOfString:@""];
			NSRange end = [holderString rangeOfString:@""];
 
			NSRange range;
			range.location = start.location;
			range.length = (end.location+end.length)-start.location;
 
			NSString *xmlString = [holderString substringWithRange:range];
 
			[self parseXMLString:xmlString];
 
			[holderString deleteCharactersInRange:range];
		}
	}
}

Here we receive data and append it to our holder string. We then check that both an opening and closing element tag is seen. If both tags are seen and the opening tag occurs before the closing tag, we create a substring in that range, pass the completed element to a method called parseXMLString and delete the characters from the holder string.

Parsing Data

Now that we have completed elements being grabbed out of the data we receive we need to parse out what we find as important. For the sake of extensibility I created a helper object called Tweet. A Tweet takes in tweet text, an author name, the authors Twitter URL, a timestamp, an image URL and a coordinate. This is the header for the class

#import
#import 
 
@interface Tweet : NSObject {
 
	NSString *tweet;
	NSString *author;
	NSURL *authorURL;
	NSString *timeStamp;
	NSURL *authorImageURL;
	CLLocationCoordinate2D coord;
}
@property (nonatomic, retain) NSString *tweet;
@property (nonatomic, retain) NSURL *authorImageURL;
@property (nonatomic, retain) NSString *author;
@property (nonatomic, retain) NSURL *authorURL;
@property (nonatomic, retain) NSString *timeStamp;
@property (nonatomic, assign) CLLocationCoordinate2D coord;
 
-(UIImage*)authorPhoto;
-(NSURL*)tweetLink;
 
@end

I implement the class like this. I include a method called TweetLink which will return an NSURL of any url within the tweet text.

#import "Tweet.h"
 
@implementation Tweet
 
@synthesize tweet;
@synthesize authorImageURL;
@synthesize author;
@synthesize authorURL;
@synthesize timeStamp;
@synthesize coord;
 
-init {
 
	if([super init]) {
 
	}
 
	return self;
}
 
-(NSURL*)tweetLink {
	NSRange httpRange = [[self tweet] rangeOfString:@"http://"];
 
	if(httpRange.location == NSNotFound) {
		return nil;
	}
 
	else {
		httpRange.length = [[self tweet] length] - httpRange.location;
		NSString *customString = [[self tweet] substringWithRange:httpRange];
		httpRange = [customString rangeOfString:@" "];
 
		if(httpRange.location == NSNotFound) {
 
			httpRange.location = 0;
			httpRange.length = [customString length];
		}
 
		else {
			httpRange.length = httpRange.location;
			httpRange.location = 0;
		}
 
		NSLog(@"URL I am returning: %@", [customString substringWithRange:httpRange]);
 
		return [NSURL URLWithString:[customString substringWithRange:httpRange]];
	}
}
 
-(UIImage*)authorPhoto {
 
	return [[UIImage alloc] initWithData:[NSData dataWithContentsOfURL:authorURL]];
}
 
-(NSString*)description {
 
	return [NSString stringWithFormat:@"Tweet:%@\nAuthor:%@\nAuthor URL:%@\nPublished:%@\nLongitude:%f\nLatitude:%f\nAuthor Image URL:%@", tweet, author, authorURL, timeStamp,coord.longitude,coord.latitude, authorImageURL];
}
@end

I will use this class to create a single object holding all of the data I parse out of the XML elements I am looking at. All that is left to do is finish my parse method to get create these Tweet objects. This is my parse method that takes advantage of Touch XML and its awesome XML parsing methods.

-(void)parseXMLString:(NSString*)xmlString {
 
	CXMLDocument *document = [[CXMLDocument alloc] initWithXMLString:xmlString options:0 error:nil];
 
	if([[[[document rootElement] elementsForName:@"geo"] objectAtIndex:0] childCount] > 0) {
 
		Tweet *tweet = [[Tweet alloc] init];
 
		[tweet setTweet:[[[[document rootElement] elementsForName:@"text"] objectAtIndex:0] stringValue]];
		[tweet setAuthor:[NSString stringWithFormat:@"@%@", [[[[[[document rootElement] elementsForName:@"user"] objectAtIndex:0] elementsForName:@"screen_name"] objectAtIndex:0] stringValue]]];
		[tweet setAuthorURL:[NSURL URLWithString:[[[[[[document rootElement] elementsForName:@"user"] objectAtIndex:0] elementsForName:@"url"] objectAtIndex:0] stringValue]]];
		[tweet setAuthorImageURL:[NSURL URLWithString:[[[[[[document rootElement] elementsForName:@"user"] objectAtIndex:0] elementsForName:@"profile_image_url"] objectAtIndex:0] stringValue]]];
 
		NSString *coordinateString = [[[[[[document rootElement] elementsForName:@"geo"] objectAtIndex:0] elementsForName:@"point"] objectAtIndex:0] stringValue];
		NSRange range = [coordinateString rangeOfString:@" "];
		NSRange lon;
		lon.location = 0;
		lon.length = range.location;
		NSRange lat;
		lat.location = range.location+range.length;
		lat.length = [coordinateString length] - lat.location;
 
		double longit = [[coordinateString substringWithRange:lon] doubleValue];
		double latit = [[coordinateString substringWithRange:lat] doubleValue];
 
		CLLocationCoordinate2D coord;
		coord.longitude = latit;
		coord.latitude = longit;
 
		[tweet setCoord:coord];
 
		//PASS TWEET ONTO WHATEVER CLASS WILL USE IT
 
		[tweet release];
	}
}

Usage

Make sure that you install Touch XML and import the MapKit framework when using this class. Customize the terms, users and coordinates for the stream method to fit what you need it for. All that will be required to use the class is the following to create and begin parsing:

TwitterClient *client = [[TwitterClient alloc] init];
[client makeMyRequest];
 
[client searchByTerm];
 
OR
 
[client searchByLocation];
 
OR
 
[client searchByUser];

Fillin the very end of the parsing method to send the tweets off to whatever part of the application you want to use them in. I hope this introduction will help you guys add live twitter streams into your apps. Happy coding!

Source Downloads

TwitterStream