Most Popular Applications

You’re seeking more applications to browse; you’re obsessed and finally your phone is overdosed I mean it is full of applications those you do not use ever.

Apple is always ready to introduce you most popular applications and by the way you save some time and money. Most popular means they are usable. So do not waste your time choose one of them and get ready to probe your new application.

All you have to do follow the reference: http://www.apple.com/webapps/index_top.html

Gartner’s Report On 10 Million 3G iPhones

Technology research firm Gartner tried to clear up reports that it had said Apple might be buying 10 million iPhones capable of connecting to much faster data networks.

Gartner said that they do not know whether Apple has actually placed an order for 3G iPhones and there is no way for them to get a confirmation that an order had been placed. However, they do believe it would be logical if Apple would have done so.

“If Apple was to place an order, then 10 million would be a reasonable number. And we absolutely believe that in the next-generation iPhone 3G will be there,” - Bob Hafner, Dulaney's boss.

The iPhone currently uses an EDGE radio, a digital mobile phone technology for increased data transmission rates over a cellular network. EDGE, however, is considered a 2.75-generation technology, versus a 3G technology, such as HSDPA, which is used in Europe.

Since iPhone sales were not as strong as expected in Europe (Apple has predicted it will sell 10 million of the current iPhone by the end of the year), due in part to a lack of 3G support, it is vital for Apple to release 3G iPhones as soon as possible. However, 3G might not be enough, since there are already 3.5G devices, reports Gartner.

Gartner announced that one improvement they expect from Apple is OLED display for the iPhone. Current LCD is the most energy consuming part of the device, and having OLED screen would allow for power balance for 3G.

Gartner, Inc. (NYSE: IT) is the world’s leading information technology research and advisory company. It delivers the technology-related insight necessary for our clients to make the right decisions, every day. From CIOs and senior IT leaders in corporations and government agencies, to business leaders in high-tech and telecom enterprises and professional services firms, to technology investors, Gartner, Inc. is the indispensable partner to 60,000 clients in 10,000 distinct organizations.

Through the resources of Gartner Research, Gartner Executive Programs, Gartner Consulting and Gartner Events, the firm works with every client to research, analyze and interpret the business of IT within the context of their individual role.

Founded in 1979, Gartner is headquartered in Stamford, Connecticut, U.S.A., and has 4,000 associates, including 1,200 research analysts and consultants in 75 countries.

Reference:

http://www.informationweek.com/hardware/showArticle.jhtml?articleID=207000174

No Mozilla Firefox For iPhone

Mozilla invited a handful of technology bloggers to come down to its office for a roundtable discussion. After long discussions about different things connected with Mozilla Firefox it became clear that no firefox would be available for iPhone.

Mozilla CEO John Lilly and VP of engineering Mike Schroepfer said that Apple’s software requirements for the device are too restrictive, and as such, they will not be making Firefox for iPhone, at least in the near future.

According to John Lilly - "Apple has not written a license which allows Firefox to run on the iPhone."

"Android and iPhone are closed platforms. There are carriers and device manufacturers who are more open with their platform, and we'll do well there - the Nokia N810 internet tablet, for example. People can just take the (Firefox) code and run with it, so there's a lot happening that we don't even see until it shows up... XUL (the language in which Firefox's user interface is written) makes it easy to experiment on mobile devices. That's our main advantage on mobile platforms." - added Mike Schroepfer.

P.S It should be noted that 10th anniversary of Mozilla will be celebrated on Monday.

References:

http://blog.wired.com/monkeybites/2008/03/mozilla-execs-o.html

On Managing iPhone & Mac Developers in the Enterprise

Apple seems to be positioning the iPhone as a competitor to the Blackberry, Treo, and other so-called smartphones commonly found in the Enterprise, and this fact has stirred up a lot of interest in the iPhone and the iPhone SDK. As a result, people with a lot of Cocoa programming experience suddenly find themselves marketable beyond the realm of the Mac. 

For companies who want to get something solid up and running on the iPhone quickly, there's really no better choice than to hire a couple of people with solid Cocoa development experience. They will hit the ground running, whereas other developers with no exposure to Xcode or Cocoa are going to have a solid learning curve facing them. People will tell you that Cocoa is easy to learn - and it is - but, like anything, it takes people a while to really wrap their heads around it fully. 

But here's the rub: Mac developers, by and large, are a different breed than the developers you're probably used to working with in your large corporate environment. The majority of them are self-employed, part-owners of a small software company, or work in small, fairly autonomous groups within a larger organization. They are used to working in an environment that is the polar opposite of what most corporations and other large organizations foster. They are not accustomed to (and many actively avoid) bureaucracy and committee-based decision making, and they are accustomed to a lot of freedom in choosing how and when they work as long as they meet deadlines and deliver a quality product.

One of the first things you need to understand about Cocoa development (and it seems almost certain that this will apply to Cocoa Touch just as much), is that the entire language and the development tools are setup to afford maximum productivity to individuals or small groups, not to facilitate large groups of developers, analysts, architects, and other pseudo-developers.  Cocoa groks the ideas found in The Mythical Man Month and rarely do you find Cocoa projects using more than a handful of developers. Do you know how many developers wrote iMovie '08? One… and he wrote it while on vacation.  There are, in fact, many examples of great software on the Mac developed in Cocoa by just one developer, and a great many more that were developed by small teams. 

So, the first rule for your iPhone team: less is more. You'll do much better getting a couple of really good, experienced Cocoa developers than a dozen coders of mixed experience levels and background. If you can't find any, invest in a good people and send them to the Big Nerd Ranch to get trained up, put them in front of a nice powerful Mac, and let them at it.

Second rule: don't ride herd on them. Get people in whom you have a high level of confidence, and then let them do their job. This is probably good advice for all employees and all development teams, but I've worked inside large organizations enough to know it's not standard practice. Resist your impulse to micromanage. It's a bad idea in general, but it could be devastating to your iPhone development team, especially if you followed the advice of my first rule and hired good, experienced Cocoa developers.

Third rule: insulate your team from corporate silliness to the fullest extent of your power. Nothing will make these people leave your employ faster than making them sit in unproductive, boring meetings that don't directly further the project. The kind of person you want, wants to be sitting in front of a Mac furiously coding away. Anything you make them do that's not that, is counterproductive and damaging to your project.

Fourth rule: forget your existing processes, project plans, and other schemes for world domination. They don't work to begin with, but they are blatantly fatal to this kind of software development. Too much process with kill your iPhone development projects faster than anything; every existing packaged process scheme is a case of the cure being worse than the disease.  The iPhone tools and design patterns are not built to accommodate the kind of oppressive over-processing mechanisms that are all the vogue in enterprise software development these days. You'd probably get more done if you abandoned it for all your software development, but in this case, it's mandatory. If you use these tools, you will fail. If your corporate policies say you have to use them, get an exception, or else outsource your development to someone who's not fettered by silly corporate rules. If you try to force CMM, RUP, SCRUM, Six Sigma or any other form of expensive snake oil that your management thinks is the silver bullet onto your iPhone development team, you will smother it until it dies a painful death.

That's about it. I'm not a management expert, but I know Mac developers, and I know enterprise IT, and I foresee trouble brewing if those in the latter insist on trying to force those in the former into a mold they are not intended for.

Beta 2 is out!

If you're a registered iPhone developer, go get it!

Refurbished iPhone For $249

AT&T has already begun selling refurbished models of the 8GB iPhone for $249, a savings of $150 off a new iPhone.

The offer requires a 2-year plan that must be ordered during the activation process. Limit is one per customer. Standard AT&T rates and plans apply. A quick check of the Apple Store online also reveals the availability of the same 8GB iPhone for $249. Apple also offers AppleCare for $69 which extends repair coverage for 2 years.

Not a bad proposal for those who have to make some savings!

New Video Converter - RockPod 08 Lite For iPhone Consumers

iPhone consumers now can use a small, useful and free software tool RockPod 08 Lite to convert videos for their iPhone.

RockPod 08 Lite converts multiple video files (even HD m2ts, evo, vobs) to iPod, PSP and Windows Mobile PDA formats.

The program is supported by 15 different options ranging from AVI and MPG through to WMV, DVR-MS and high-definition television formats such as DVR-MS and M2TS. It works on Windows 2000, XP and Vista. While the new version is available for Windows 2000, XP and Vista, a Linux update is expected shortly.

You can even choose a file size to which videos should be re-encoded, amongst other options like quality and multiple file encoding.

The new build sees a small change to the interface but it still appears to be one of the simplest multi-file converters available.

References:

http://techlogg.com/rockpod/

Getting Started on the iPhone: A Primer for Non-Mac Development Shops

What do you do if you're an existing software provider and you want to get into doing iPhone Development? Well, if you're already a Mac developer using Cocoa, you're probably already elbow-deep in the SDK and having a blast. But if you're a mobile developer who has worked with other platforms, or if you are primarily a Windows or Java shop,  the prospect of getting into the iPhone is probably daunting. You've likely had some of your developers sign up for the SDK and start reading up, and chances are they're having a a lot of big WTF moments.

So, let's take it step-by-step. How do you get up to speed quickly if you're completely new to objective-C, Cocoa? Here's a high level plan for you.

1. Join the Apple Developer Connection or ADC. This is Apple's developer support organization, similar to MSDN. There is a free membership available, but splurge for at least the Select membership, which entitles you to a hardware discount, some one-on-one support with Apple engineers, and access to Apple's compatibility labs. You'll also become seeded, which means you'll get early access to software, including versions of the iPhone OS. If you're serious about bringing existing applications to the iPhone as quickly as possible, consider splurging for the Premier membership. Make sure anybody on your team who's going to be looking at the SDK signs up with at least a free membership so that they are covered by the iPhone SDK.
2. Have your developers learn Objective-C. At first, don't worry about Cocoa (the application building framework), just have them learn the syntax and nuances of the language it's based on. Your more advanced developers can probably get by with just reading Apple's language reference, as it's a relatively simple superset of the C language.  There are other books that will take you a little more by the hand through the language for people who need it. Unless your folks have worked with something like SmallTalk before, some of Objective-C's syntax is going to feel alien at first, but it's really an elegant and rather fun language to work with once you get over the initial hump. 
3. Buy some Macs. If you've downloaded the SDK, you've probably already figured out that you need a Mac to code for the iPhone. And you need an Intel Mac, and it has to be running Leopard (the latest version of Mac OS X - it's version 10.5). If you joined ADC as I recommended above, you can get a substantial discount on buying your hardware, which is why I had you do that before buying any hardware.
4. Learn Cocoa. Cocoa Touch is a bit different from Cocoa, but a lot of the design patterns, and all of what Apple calls "Core Foundation" is common between the two, so it's a good idea to learn it, even though a lot of the stuff won't be directly relevant to coding for the iPhone. The Big Nerd Ranch offers training classes in Cocoa that are supposed to be excellent. There are also several books out there on programming Cocoa, unfortunately, as of this writing, none of them have been updated to use Objective-C 2.0, the version of the language used to develop for the iPhone.
5. Start dissecting the sample code. Play around with the iPhone templates in Xcode, and browse the API documentation. Experiment. Play. Do a bunch of stuff wrong before starting on porting or re-writing any of your applications.

Okay, I know you were expecting something better than step 5. Unfortunately, because the iPhone SDK is under NDA, and will be until June, nobody can publish books or articles on how to code in Cocoa Touch until that time without violating their NDA. Places like the Big Nerd Ranch can't offer classes prior to June (although I notice they're thinking ahead and have an iPhone class scheduled for September - sign up now if you're interested, their classes often sell out).

If you want to be one of the first ones out of the gate, and you aren't a big enough company to warrant special attention from Apple and don't have deep enough pockets to lure away their existing iPhone developers, you're basically stuck with this approach for now. You need to let your developers experiment in lieu of formal training, or else you need to resign yourselves to waiting and losing the competitive advantage of being an early entrant into an emerging market.

iPhone To Become A Great Tool For Doctors

Arrival of the SDK is already connected with a lot of new events about iPhone. Here is another novelty - iPhone may become a great tool even for doctors.

“If you could use the gesture-based way of manipulating images on the iPhone and actually manipulate a stack of X-rays or CT scans, that would be a huge selling point,” - says Adam Flanders, director of informatics at Thomas Jefferson University.

The reason why mobiles couldn’t handle high-res images before is they had lack of processing and memory power. But iPhone is different. With its powerful ARM processor and 8 GB/16 GB of memory it’s well suited for such tasks. And the iPhone's new business-friendly security features may ease privacy fears, physicians say, and could even turn the device into an indispensable medical tool if hospitals OK the device.

“The real beauty of the iPhone is that it offers a richer 3-D experience and more memory,” says Michelle Snyder, vice president of marketing and subscription services at Epocrates.

Tech-savvy doctors have been speculating about the iPhone's medical potential long before Apple shipped its first unit. But the lack of native application support has meant that, up to now, all iPhone applications had to work through the phone's Safari web browser. That's a nonstarter for most medical applications because it demands constant connectivity (either via WiFi or an AT&T cellular data network) and prevents application developers from using the device's full processing power.

The only problem of this novelty is its privacy. And here comes a question: Can hospitals guarantee patient privacy when data is being stored or accessed on iPhones? And can the popular handset stand up to the rigorous demands of a busy hospital environment?

P.S We will see it when the new version 2.0 of the iPhone's firmware becomes available, this June.

References:

http://www.wired.com/gadgets/mac/news/2008/03/iphone_doctors

iPhone Consumers - Active Users Of The Web

A new study from measurement firm M:Metrics confirms, that iPhone users are tend to check the web more often than the users of other mobile devices.

After charting the habits of more than 10,000 adults for six months after the iPhone's U.S. launch, M:Metrics concludes that nearly 84.8% of iPhone purchasers regularly use their handheld device to access news and other content on the web.

The study found that 58.6% of iPhone users visited a search engine on their phone, compared to 37% of smartphone users and 6.1% of mobile phone users. 30.9% of iPhone owners watched mobile TV or video, versus a 4.6 market average, and more than double the rate for all smartphone users.

Finally, 74.1% of iPhone users listen to music on their iTunes-equipped devices. Only 27.9% of smartphone users listen to music on their phones and 6.7% of the overall mobile-phone-toting public listens to music on their mobile devices.

"Two featured widgets, YouTube and Google Maps are extremely popular among iPhone users: 30.4% accessed YouTube and 36% used Google Maps," - said senior analyst for M:Metrics, Mark Donovan.

Social networking is also popular among iPhone users: 49.7% accessed a social networking site in 2008 January, nearly twelve times the market average. 20% of iPhone owners accessed Facebook, one of the first Web properties to customize its content for the iPhone, versus 1.5 percent of the total mobile market.

"The iPhone has certainly delivered on its hype. Beyond a doubt, this device is compelling consumers to interact with the mobile Web, delivering off-the-charts usage from everything to text messaging to mobile video." - said Mark Donovan.

The study showed that iPhone owners, like other smartphone owners, tend to be male, aged 25-34, earn more than US$100K and have a college degree.

References:

http://bits.blogs.nytimes.com/2008/03/18/iphone-users-are-mobile-web-junkies/

Network Communications with NSFileHandle

Okay, well, because of the NDA, I can't post code samples about how to do things using the iPhone SDK yet, but I can post regular old Cocoa code without worrying about the Apple lawyers. If that code just happens to be usable on the iPhone also... oh, well.

With the fact that so many people have downloaded the SDK, I have to think at least seven or eight of those people do not have any prior experience using Objective-C or Cocoa. Those people will have a bit of a grokkng curve. I say "grokking" instead of "learning" because the syntax of Objective-C is straightforward and relatively easy to learn. However, the approach it takes is decidedly different from the application frameworks used with Visual Basic, C#, and Java; it takes a little while to really understand the way it all fits together and start working with the frameworks rather than against it.

One of the things that I'm sure many aspiring iPhone developers will want to do in their applications is to communicate with remote servers. Now, any of the old school C programmers who want to do so will have access to BSD sockets and can do network programming just as they have always done. Because Objective-C and Cocoa build on top of C, you always have available to you everything you do when writing procedural C.

But, often, there's a better, or at least, an easier way to do things using existing Cocoa classes. Unfortunately, what that "better way" would be for this isn't quite so straightforward. One option is to use CFNetwork. CF stands for Core Foundation, and when you see something beginning with CF in the world of Apple software development, you are looking at lower level C functions that are used by the higher level libraries like Cocoa and Carbon. CFNetwork underlies many of the higher-level classes capable of communicating with remote servers. When you use NSURLConnection, or instantiate an NSString using stringWithContentsOfURL:encoding:error:, you are using classes that sit on top of CFNetwork.

And CFNetwork is great - it is robust and written to work with an existing run loop mechanism, meaning you don't have to detach threads to keep from blocking. Unfortunately, CFNetwork is conceptually hard and using it in Cocoa creates confusing, hard to maintain classes. Coercing C callbacks into an instance of a Cocoa class works, and it works well, but it just doesn't feel right in the context of Objective-C/Cocoa.

Unfortunately, there is no generic Cocoa class for accessing remote servers. There are lots of special-purpose methods and classes that sit on top of CFNetwork and let you seamlessly get information from over the network using URLs. But what can you do if you want to implement your own protocol, or access a different kind of server?

Well, there are several third party classes that you could use for this, including Dustin Voss' free AsyncSockets and the open source SmallSockets project. These are both good options if you want to use them.

Someone on the Cocoa-Dev mailing list recently pointed out that NSFileHandle is capable of handling socket communications, but you have to actually create the socket the old fashioned way and feed it to NSFileHandle using initWithFileDescriptor: to do so. Thanks to the beauty of Objective-C categories, however, you only have to do it once if you write the code generically and put it in a category.

So, thanks to the help from several people on the Cocoa-Dev list, I present a category on NSFileHandle that lets you get a conection to a remote server. You can download the category right here.

Using this category is very straight forward. You can create a new NSFileHandle that is connected to a remote server like this:

NSFileHandle *fh = [NSFileHandle fileHandleToRemoteHost:@"theremoteserver.com" onPort:80];

To send a command and get the response, you need to create a method (probably on your controller class) that will be called whenever data is available on the read stream. That method might look something like this:

-(void)process:(id)notification
{
   NSFileHandle *fh = [notification object];
   NSMutableData *data = [fh availableData];
   NSString *dataString = [[NSString alloc]
     initWithData:data
     encoding:NSUTF8StringEncoding];
   /* Process the data however you need to here */
   [dataString release];
   if (booleanVariableThatIndicatesIfWeExpectMoreData)
     [fh readInBackgroundAndNotify];
}

Notice the last two lines. If we are expecting more data, we have to call readInBackgroundAndNotify again, or it won't continue to pull more data from the stream and we'll end up with only part of the server's response. If we don't expect more data, we don't have to call readInBackgroundAndNotify any more, and could also close the stream using the closeFile method of NSFileHandle. You could also leave the stream open and send more commands to it. 

If you call readInBackgroundAndNotify and there's nothing to read, your program won't be harmed, but your method won't get called again unless you send another message through to the server. So, if you have processing to do on the retrieved data once you get it all, you need to figure out in your code when you've received everything. Usually the protocol gives you a mechanism for doing that. NNTP, for example, sends a line with just a single period on it to tell you when it's done sending you data, but it leaves the connection open in case you want to send more commands through.

The nice thing here: no threads. Our application goes about its merry way, and calls us back when there's something for us to do. At this point, we've created the file handle, and we've created a method to process the responses from the server, so now we just need to send something to the remote server so that our process: method has something to wait for, which we do like this:

[fh writLine:@"HELO\r\n" withObserver:self andProcessWith:@selector(process:)];

That's all there is to it. 

As I said before, this is Cocoa code, not Cocoa Touch code, but since NSFileHandle is part of the Foundation framework and not the AppKit, it should (in theory) work unchanged in Cocoa Touch. I haven't yet tested it, but I'm going to, and as soon as the NDA lifts in June, I'll tell you if any changes are necessary to get it to work on the iPhone.

Dress your iPhone

“Elega pouch”
for everyday life

“Magnet Flipper cases”

for business meetings

“Dockable cases”

during the work

“Leather Skin cases”

at your romantic appointment

Or maybe “Ultra Slim pouch”

to emphasize the figure

You can make a lot of present for your iPhone. Sena Store offers these and many different styles and colors of iPhone “clothes.” Make your choice and be sure you two will attract some ones attention.

Reference:
http://www.senacases.com/Brands/Apple-iPhone-Cases

Problems Reading and Writing Files on the iPhone?

If you're having problems reading or writing data using the beta iPhone SDK, you should head over to the iPhone Dev Site at Apple, and download the SQLiteBooks sample code they just posted. There's a workaround in the App Delegate of that project for the problem. 

I can't give details because of the NDA, but if you're trying to do any file reads or writes, or to use SQLite, you should check out the new sample code to find out how to get those working.

Booxter Multiple Libraries For iPhone And iPod Touch

Deep Prose Software has launched Booxter 2.0.7 for Mac OS X. With Booxter users can create multiple libraries and smart lists to organize books, music, movies and comic books. The upgrade adds a new HTML export feature for iPod and iPhone touch users.

The way it works is by scanning (or taking a picture with iSight web-cam) a barcode, which is then compared to numerous online libraries and added to your collection. You can variously filter, tag and search your listed items. Booxter supports both handheld and wireless barcode scanners and iSight video cameras to add large numbers of items to a collection.

Version 2.0.7 adds a new HTML export feature for iPod and iPhone touch users so that they can view their libraries on the go with an internet connection. Booxter requires Mac OS 10.4 or Mac OS 10.5. The free version has a limit of 30 items for each library. The full version costs $49.99 USD.

All customers who purchased Booxter in 2007 will receive free updates, and all other Booxter customers will receive coupons to upgrade to the new version at a generous discount. Booxter is Universal Binary so runs natively on both PowerPersonal Computer and Intel Macs.

The Deep Prose web store sells USB and Bluetooth barcode scanners which complement Booxter and provide a complete integrated solution for collectors.

References:

http://prmac.com/release-id-1595.htm

iPhone Users Get Involved in Training and Diet Planner

Iphone users now can allow themselves to get involved in a special training and diet planner that is available via safari browser. If you’re one of them who need to manage personal menu, keep the diet or a dairy of everyday food activities you should simply login to your account on your iPhone and view your gym training for the day, diet and manage your weight goals all from the iPhone interface. It is easy to use, and free to create an account.

FitReach provides you with a way to measure and manage your fitness and diet program. Whether you want to achieve the body you have always dreamed of or improve your overall health FitReach can help keep you on track and motivated.

Other great features include the ability to see what diets and training programmes are working for other members, if something isn't working for you - see what is working for other people and amend your training or diet.

So if this program is appropriate you may act and check it out on http://mobile.fitreach.com/

Brain Surgery?

Craig Hockenberry has an interesting post on his blog today about the iPhone background processing issue. Craig speaks from personal experience on this matter and I'd classify his post as a must-read  for anyone who has an opinion on the background processing issue in the official iPhone SDK.

Unfortunately, his posting comes off as a bit smug and superior for my personal tastes. Though I have tremendous respect for Craig's ability, this posting comes across as a "shut up you naughty children, you're not as smart as me and Apple so you can't have an opinion on this". It is definitely true that he has first-hand experience that most of us don't, but since the decision he's justifying is one that prevents us from gaining the very experience he's claiming we need in order to have an informed opinion (without jailbreaking our phones, at least), I'm finding the argument a bit circular for my taste.

To work with Craig's own metaphor: Don't cut off our hands to keep us from shooting ourselves in the foot. Some of us idiot developers who are apparently not smart enough to have an opinion on this, might just surprise you by finding a way to work around the problems you encountered. Or, just maybe, our applications have different background processing needs than the one application you've tried this with. Since Apple has set themselves up as gatekeeper to the App Store, and since no self-respecting developer is going to ship a product without testing it extensively on a real iPhone first, I don't see the need for such drastic exclusions from the SDK itself. They could control this by subjecting apps that use background processing to greater scrutiny, or providing a sanctioned mechanism that can enforce limitations, not by making those parts of the iPhone completely verboten.

The iPhone and the Enterprise

With Apple's simultaneous announcement of the iPhone SDK and the licensing of the protocol needed to work with Microsoft Exchange servers, it does seem like Apple is finally getting serious about pushing into the Enterprise. I've worked a lot in this realm, and have long felt that Apple's development tools - especially Cocoa — which started life as NextSTEP — was especially well suited to doing the type of custom development that I've seen such a desperate need for in the Enterprise. Though most people aren't aware of it, the tools underlying the iPhone SDK as well as those commonly used for doing software development for Mac OS X have long-since been proven in the Enterprise environment.

I've spent spent close to a decade working in Enterprise software, first as a developer at PeopleSoft, and afterwards as an implementation consultant. During most of this time, I have wished there was some way to convince all these big, predominately Windows-based shops that there was something better available. But "Apple" is a dirty word in most large corporate IT departments, and Apple has never really seemed interested in challenging that. Old ideas persist long after they are no longer supported by facts. The fact that OS X is a solid Posix-compliant Unix which runs Microsoft Office, supports Windows printing and file sharing, and has virtually no impact from viruses or malware doesn't seem to hold much sway even when it is known. It is sheep mentality at its worse, but there it is. 

Large corporations are not known for encouraging individuality, and no decision is ever made by a single person at most large companies. I think Heinlein's description of decision by committee is spot on: He described a committee as a beast with multiple heads and no brain. Any committee is less likely to reach the right conclusion than any individual member is. The whole is considerably less than the sum of its parts in this context.

Most of places I've done work for also balk at even hearing the term "custom software"; bizarrely enough, they are frequently willing to spend literally millions of their corporation's dollars to implement so called "Enterprise Software" - software to handle some set of tasks less efficiently than what they could have had by hiring a couple good Cocoa developers for a month. These projects often fail, and rarely do they come in on-time or under-budget, even when the schedule and budget are luxurious. Despite that, suggesting to a large American corporation that they develop in-house solutions in Cocoa would be openly laughed at. "It's not Windows" has been a sufficient argument against that idea for well over a decade now.

In the short term, I do not see the situation changing, but if the iPhone sees any serious penetration into the Enterprise market (and it certainly seems poised to), it could expose a lot of people to just how awesome Apple's development tools are. Shops that want to develop custom iPhone apps will have to buy some Macs, and will have to hire or train Mac-savvy developers. Like a benevolent virus, a love for Cocoa tends to be infectious, and some hands-on experience with modern Macs might just disabuse some of the Corporate IT drones of their outdates ideas about just what a Mac is. 

I've worked on projects where handheld clients to ERP applications were being implemented. Though I've never been directly involved with the mobile implementation work, I have been involved enough to see that the offerings tend to be expensive, not particularly intuitive or easy to use, and often require you to hire the vendor's consultants if you've customized your system at all (and everybody customizes their system). In my experience, I can't recall having seen a mobile client to an ERP application whose functionality couldn't be replicated in a couple of days for the iPhone.

I would conservatively guess that a company willing to standardize on the iPhone OS and do custom development for their mobile needs could reduce the cost of their mobile implementation in half. Savings of 90% or more are absolutely not out of the question.

We do live in interesting times.

Lotus Notes E-Mail for iPhone 2.0 By IBM

IBM is working on Lotus Notes e-mail application for iPhone 2.0, as IBM spokesman Mike Azzi announced. But there are some details that are not revealed yet.

There are 140 million Lotus Notes and Domino users worldwide, according to IBM, and it would be very wise for both Apple and IBM to release it faster. So far Microsoft Exchange is number one platform.

Lotus Notes developers would build a Notes e-mail application for the next-generation iPhone by using Apple's SDK announced last week and would distribute it over Apple's new AppStore. AppStore allows developers to wirelessly deliver their applications to iPhone and iPod Touch users.

Apple plans to allow developers to charge whatever they want and to allow the developers to keep 70% of the revenues, while Apple keeps the other 30% to cover the cost of running AppStore.

Apple Inc. officials would not comment on Notes for the iPhone either, but released a statement saying that 100,000 developers had downloaded the beta SDK (software development kit) for the iPhone in the first four days since its release. Several developers are named, but there is no mention of Lotus Notes.

Reference:

http://www.pcworld.com/article/id,143440-pg,1/article.html

Still Playing

I started working with the audio toolbox on the iPhone today. This morning, I added sounds to the little dice rolling application I've been writing. I recorded a total of fifteen sounds, five of a single die being rolled, five of two dice being rolled, and five of four dice being rolled. I let my kids roll the dice while I recorded the sounds, which they thought was cool, although they can't understand why I can't put the program on my iPhone. 

Do you hear that, Steve Jobs? You are making my kids sad. Do you really want that on your conscience?  ;) 

Unfortunately, the "Coding How-Tos" on the iPhone web site don't give a full code sample on how to play audio files. They show the command to play a sound, but not how to find and load the file from your application bundle (it may be in the how-tos somewhere, but it wasn't under the section on playing audio). Figuring that out took a little poking around in the documentation and header files (and, of course, a couple of application crashes), but I got it working without too much trouble. 

Boy, it's been a while since I've worked with pointers... I spent way too long working almost exclusively with Java. I don't want to bash Java - I know a lot of people like it, and it's been the basis for a lot of my income over the years - but it just feels so much less elegant than objective-C. 

Since I wrote my first AppleScript Basic program in 1980, I have used literally dozens of different programming and scripting languages, many extensively and as part of my professional life, and I can say that Objective-C and Cocoa (and now Cocoa Touch) are, by far and without a doubt my favorite. They take a little while to understand when you first start using them, but once you get over the "grokking curve" and really start to understand how it all pieces together, coding in objective-C really becomes a pleasurable experience. It's just plain fun. 

In a way, I envy all those people coming to the iPhone from other languages and toolset. They are about to discover something very, very cool if they have the patience to get past the initial obstacles.

Download YouTube Videos To Your iPhone Via MxTube

MxTube, a native program for the iPhone essentially allows you to download YouTube videos onto your iPhone. But for now MaXtube offers iPhone consumers to download desired YouTube videos to iPhone and watch it later, skipping the main computer.

The program works via a pseudo-Youtube-interface, so one can download a video via WiFi with a high quality setting or a lower quality setting via Edge.

In order to install MxTube and download YouTube videos onto your iPhone, you need to have a jailbreaked iPhone with Installer.app on it. Make sure you have “Community Sources” added, then locate and install the program.

To install, find it from Installer’s “Multimedia” category and to download, run a search as you normally would and select the video you want to download. As YouTube has two versions of every video, high and low quality for downloading it you can select high, low or both. The videos will download in sequence and in the background. Once it's done downloading, the video is available from within the application.

The MxTube application searches and saves YouTube videos directly to your iPhone or iPod touch so you can play them back at any time, whether you've got an active internet connection or not.

References:

http://www.winandmac.com/mobile/iphone/download-youtube-on-the-go-with-iphone/

http://mxweas.com/blog/

A Splash of Cold Water

I would imagine I'm not the only person who received notification from Apple today that I'm not accepted into the first round of iPhone developers. I understand that they're probably giving priority to their more prominent development partners and that they don't have the resources to support everyone, but boy, it's a tough pill to swallow. Especially since Apple is so quick to publish press releases lauding just how many people have downloaded the SDK; they never make mention in those press releases of the fact that not everyone who downloads it will actually get to it fully.

Frankly, I'm not that all that irked about not getting access to the App Store. I'd like to have that option available to me, but what I really, really, really want is to be able to test my apps on an actual iPhone. I bought a new iPhone last Thursday with its own phone line just so that I would have one that I could install the 2.0 OS onto without fear of screwing up my main phone. And now, I can't use it for that purpose and don't know when I will be able to.

I'm bummed.

Daring Fireball on "One App at a Time"

John Gruber, Mac blogger extraordinaire, has a post today about what I consider to be the most glaring problem with the iPhone SDK. I don't know John, but I rarely disagree with him on matters related to Apple, but although I think he makes good points about WHY Apple chose to put this limitation on the SDK, I disagree that Apple should be the one making this choice. If a user wants to put a program on their iPhone that will reduce their battery life, that should be their choice. Apple is requiring all apps to be reviewed, so in theory, an app that went overboard or impacted the network would be stopped by them in their role as App Store gatekeeper.

There are many, many potential killer apps for the iPhone that simply can't be created without some way of running code in the background. If they can't allow this, then there should be some alternative available. Maybe there is, and it's buried in the SDK somewhere, but I haven't found it, and I've been looking pretty hard since last Thursday.

Apple obviously recognizes the need for this, since they do it themselves in Mail. It seems pretty obnoxious to say "yeah, we need to do this, but you can't. Ever." Yeah, I know it's their phone, and they can pretty much do anything because they wrote the software that runs it, but I think this limitation is potentially devastating in terms of the iPhone reaching its full potential as a "mobile platform", especially one that Apple seems to be positioning for a push into the Enterprise market.

It seems there must be a way to address their concerns, and yet make it possible for apps to do things when they are not being run.

An iPhone App

I really hate the chilling effect the NDA is having on the iPhone developer community right now. There is no mailing list where we can talk tech about this, or ask others for feedback, and we have been admonished not to talk about it even on Apple's official Cocoa-dev mailing list, where developers turn to each other for help with coding problems.

I understand, to some extent, why Apple is doing this, but given the fact that any Schmoe can sign up for an ADC free membership and moments later download the SDK, it seems a little overkill. I would fully agree and understand this if, like most pre-release software, the SDK was seeded only to Select and Premiere members of ADC, but since it's not, it's bordering on silly. It's like putting a notice on a bulletin board and then asking people not to talk about it. Except that Apple has a means of enforcing this edict, and it's one smart developers are not going to risk facing, since it will have a pronounced affect on their bottom line.

I may not be able to share the code or write a tutorial about how I did it, but I certainly can show you a screenshot of the little app I hacked out last night. This took me about two hours: a little less than one hour for the code, and a little more than an hour to take the pictures of the dice, crop and resize the photos, and make the icons.

Developer Certs and iPhone OS 2.0

One of the things that seems to be causing a lot of  iPhone developers grief at the moment is figuring out how to get the iPhone applications they are creating to run on the iPhone rather than on the simulator that comes with the SDK. This issue has annoyed me as well, so I've spent some time trying to get to the bottom of what one has to do.  I thought I'd take a second to explain the situation as I understand it. Now, this isn't official, I'm just telling what I've been able to glean from reading, experimenting, and talking with people. It could be wrong, but I don't think I am.

One that Apple states is that you need a developer certificate to run an application on an iPhone. The documentations goes so far as to tell you how to create one, but there is currently no way to upload one to ADC. You can't upload one until you've been accepted as an iPhone developer, and so far, I haven't heard of anybody who's been notified that they've been accepted. It's possible that some people have, but everyone I've talked to is still anxiously waiting.

But more important than the developer certificate is the fact that Apple hasn't released the 2.0 beta version of the iPhone software which is needed to run third party apps. In other words, even if we had our certificates, we couldn't actually do anything with them at the moment because our phones need to be updated to run these apps.  Rumor says the beta version is going to be released very soon, but there's no official word out of Apple about it yet.

Unfortunately, the bottom line right now is that we have to be patient.

Good Googly Moogly! 100,000 downloads

Ars Technica is running an article claiming that the iPhone SDK has been downloaded 100,000 times! I knew there was excitement in the air over this thing, but holy cow.

On Censorship and the iPhone Application Store

One of the complaints I've heard from many people about Apple's approach with the iPhone SDK is that they have retained an awful lot of control over what developers can do with it. You have to be approved by Apple to get a developer certificate, all your code must be signed with that code certificate to run,and your applications must be reviewed by Apple before they can be sold.

While I understand why Apple is doing this (sort of),  I still think it's a valid concern on the part of us developers. This is a "Big Brother" level of control that Apple is demanding over us, and I think it's going to stifle development and annoy some of the most stalwart supporters of the company. I don't think people will refuse to develop for the iPhone as a result, simply because the iPhone has such huge potential and offers a rare opportunity to be part of an emerging market, but I do think it will have a negative impact.

I certainly understand Apple's stance against malicious applications. What I don't understand is why Apple is including content restrictions. Why is Apple requiring iPhone applications to be family friendly, but yet is currently selling thousands and thousands of songs with explicit lyrics, and movies with nudity. Why can they peddle Natalie Portman's naked derriere on iTMS, but the same content as part of an iPhone application would be inappropriate? Or would it? 

And that's the big issue I have: it's arbitrary. There are no guidelines for developer to follow, no parameters defining what really is okay and what is not. Apple could simply say "no" for no good reason, or even to stifle competition the way Microsoft is known to do. I'm not saying they will, and I hope they don't, but they've given themselves that much lattitude. 

The restrictions against "illegal" and "malicious" software I understand, as well as the restrictions on those that use too much bandwidth or have privacy implications. But "porn" and "unforeseen" are both incredibly vague categories and basically say "whatever we don't want to let you put on there".  Certainly, my idea of what constitutes porn and for example, James Dobson's idea are probably radically different.

I have no problem with certain constraints being placed on me in exchange for getting ready access to iPhone users, but I want to know what those limitations are before I invest countless hours in developing an application.

I Love Mac Developers

I mean that in all sincerity. They really are a diverse and interesting lot, and for the most part, very smart. Most of the people blogging iPhone development right now are from the Mac development community, which makes sense. Since the iPhone SDK is so similar to Cocoa, so these folks have a leg up. 

I haven't been actively participating in Cocoa or Objective-C circles for close to two years, but the release of the iPhone SDK has pulled me back in. It is very refreshing to be immersing back into it.  This is a great and really helpful group of people. Almost every time I've ever had a Cocoa problem that I couldn't resolve myself after researching, I found someone on Apple's Coco-Dev mailing list who would point me in the right direction. It's better tech support than most companies provide their paying customers. It is a community. Now, I know that word gets thrown out a lot with respect to the internet, but in most cases, it's misapplied. Not so for the Cocoa development community.

Anyway, studying the iPhone SDK documentation, I started looking for information on how much memory was in the phone, and how much as available for your application to use. I'm not talking about the widely touted 8 and 16 gigs of persistent flash memory in the phone, but the amount of volatile physical memory. It turns out finding this information is not straightforward at all: Apple does not include this information in the iPhone specs page nor could I find it any an of the SDK documentation. I broadened my search out to the interwebs, which led me to Craig Hockenberry's blog and more specifically this entry. It didn't take long for some smart person (aka Craig, in this particular case) to identify the hole in the documentation and plug it. He could have kept this information to himself, giving him a leg up on a great many developers, but instead, he chose to share it.  For those of you who didn't click the link, the answer I was looking or is that the iPhone has 128 megs of RAM, with 64 being available to a running application.

Of course, once I found Craig's blog, I started reading through the entries. I did this partly because I like the way he writes, but also because part of my (second) job right now is to find out everything I can about the iPhone and the iPhone SDK, and Craig certainly seems to be knowledgeable in this regard. I must say, though I don't know Craig personally, I'm rapidly becoming a fan of his. I especially like this post where he suggests raising the barrier to entry for iPhone development by charging $499 instead of $99 to become an iPhone developer. I know this probably will not prove to be a popular opinion, but it's one I agree with, although I would propose a slightly different approach. Instead of raising the price substantially for becoming an iPhone developer, instead, simply don't make it an option for ADC Free members. 

Is iPhone a ‘Businessman’?

$100 million "iFund" was created by Kleiner Perkins Caufield & Byers to support new companies developing the next generation of applications. And “health care” was one of the major reason for Kleiner Perkins partner John Doerr. So I think they will do everything to make iPhone a business device.

Many businesses demand the device to work better with their corporate e-mail systems. So, during the event at Apple's headquarters, Apple said it’s planning the iPhone to support Microsoft Corp.'s Exchange software and at this way it’ll solve all problems in the gadget and will put it in more direct competition with Research in Motion Ltd.'s BlackBerry and Palm Inc.'s Treo smart phones.
“The software update will give iPhones the security and integration of e-mail, calendars and contact lists that businesses have been demanding,” said Philip Schiller, Apple's senior vice president of worldwide product marketing.

Plus the company's decision to allow developers some access to the closed device to build iPhone applications will hasten its development, even though the access is only through the Web and not to the same software Apple developers use.

Yes, iPhone will become a businessman.



Reference:
http://www.foxnews.com/story/0,2933,335749,00.html

Rogue Amoeba

Paul over at Rogue Amoeba has an interesting post on the "Under the Microscope" blog. It's a list of defect reports that people at Rogue Amoeba have filed about limitations with the iPhone SDK that they feel are unreasonable. This is the right way to let Apple know; they do listen, especially if they hear the same thing from a lot of people. So, if you agree with any of his points, make sure you open a defect: There is power in numbers. 

A few of the defects that Paul lists, I happen to agree very passionately with. A few others I really don't have much of an opinion about simply because I just can't seem them impacting my ability to develop the apps I want to develop, or to use the phone the way I want.

There are a few others where, even though I might agree personally, I think that they are just tilting at windmills; AT&T, for example, is not going to allow VOIP applications on EDGE if they have any way of stopping it. And, let's face it, it is their network, like it or not. A VOIP app would let people use their unlimited data minutes instead of their limited pool of voice minutes to make phone calls, meaning nobody would ever bother paying for their more expensive plans. Corporations exist to make money; AT&T is never going to let this one go without a fight.

Now, a few years from now when the iPhone is no longer exclusive to AT&T, and it's a well-established platform with a thriving developer community, that will be the time to try and shrug off these particular shackles, but not now. I'm sure this is not just Apple being arbitrary; I am sure they have specific things in their contact with AT&T that they simply can't do on the iPhone, as well as things that they can't allow others to do.

I'm sure Apple is being cautious also because they are relatively new to the mobile space, and they do not want the bad publicity of being blamed for, say, bringing down AT&T's network with something that they did or allowed to be done. They certainly do not want to see headlines about iPhone viruses hit the wire. In this market, Apple has more naysayers than they do in the computing world, and they have plenty of naysayers in the computing world. 

For my own part, I would love a completely open system, but I understand that the practical realities of the situation just isn't going to allow it now. Just like Apple to agree to use DRM on all tracks on the iTMS at first, I'm sure Apple had to agree to certain distasteful terms with AT&T in order to get their foot in the door in the competitive and highly regulated cellular phone market, and on those turns, developers can yell and stamp their feet as much as they want, but Apple's not going to budge.

Here are, the issues he mentions that I will be opening my own defects for: 

Allow applications to be installed at the user's discretion, not Apples

I'm not really hopeful about this one, but I do agree with it. You pay $400 or more for your iPhone. You own it. You should get to choose what you install on it, without having Apple, Inc. playing Big Brother.  The fact is, the iPhone is already jailbroken so people who want to write malware are not likely going to use the official SDK anyway. As a result, there's really no good reason for maintaining this insane level of control over what third party developers do.

On the other hand, I'm not going to refuse to develop for the iPhone simply because of this.

Allow applications to run in background on iPhone

Oh, yeah. This one really is a make-or-break item in my mind. Without the ability to at least run a small helper daemon. Many of the ideas for killer apps simply can't be done. Several of my ideas hinge on finding SOME way of running code when my application is not open. Apple does this with mail and calender, so there's no technical reason to disallow it and they're setting a very obvious double-standard here. I'm sure they're concerned about what people might do with the ability to run background apps, but since apps have to be approved to go on the iPhone App Store, and the platform was jailbroken months ago, this would seem to be a completely overzealous restriction. 

Allow iPhone applications to access the docking port.

Just like with background processes, Apple does this with a good chunk of their applications, but they won't provide a mechanism for doing it other than doing network communications, requiring a server application running on the host. This one is patently ridiculous as well. We should not have to jump through hoops to communicate with the host computer.

Several of the others he mentions are things that I would like to see, but these three are the ones that will have the most impact on my work. The inability to do background processing is the one that will hurt me the most personally (by far), as most of the ideas I'm working on require at least some ability to do things when my application is not being run.

While I personally would like root access to my iPhone, I don't see it happening, and don't see that most users and most apps need it. VOIP would be cool, but I'm not much of a talker, and doubt I'll even come close to using my 400 minutes of talk time most months, so having a free way to spend more than 400 minutes a month talking on my phone is not really a big draw for me.

Gameloft To Release 15 iPhone Games In 2008

Gameloft plans to release more than 15 games for the iPhone by the end of 2008. On the bases of the newly-released SDK, the company’s development teams have already begun working on the games.

Though the SDK was recently released, games will only be available to purchase once the App Store, featuring third party applications that can be downloaded to your device via WiFi or EDGE, launches in June 2008.

“The Apple iPhone has changed the way consumers perceive and interact with their mobile phones, and the release of the SDK is a tremendous opportunity for Gameloft to apply its creative and innovative approach to mobile gaming. Due to our investment in creating one of the most advanced and creative development studios to date, we are ideally positioned today to seamlessly integrate new opportunities and quickly produce games that are as evolutionary as they are enjoyable,” - said Michel Guillemot, President of Gameloft.

Gameloft is a leading international publisher and developer of video games for mobile phones. The company creates games for mobile handsets equipped with Java, Brew, or Symbian technology.

Gameloft has a direct marketing a sale presence in 16 countries. Its games are distributed in more than 75 countries through agreements with over 170 wireless carriers and 150 partners and its online shops.

References:

http://www.gameloft.com/

http://www.ilounge.com/index.php/news/comments/gameloft-to-release-over-
15-iphone-games-in-2008/

And We're Off...

Last Thursday, Apple announced the iPhone SDK (that's Software Development Kit for you non-techies), and I promptly signed up for developer status. In doing so, I have to comply with an NDA (non-disclosure agreement), so you won't be finding any technical details or code samples in this blog until at least June, but I am going to start writing my high-level impressions of what it's like to develop for the iPhone as I work through it.

I spent the last weekend chugging through over a thousand pages of technical documentation on the iPhone and the iPhone SDK, as well as writing some fairly simple iPhone applications in order to get a feel for the platform. I must admit that I am seriously excited. This is one heck of a mobile platform.

The funny thing is, I've never been excited about "smart phones" before. Not in the slightest. I never cared for Blackberries or Pocket PCs, seeing them always as a way to be further chained to work and nothing more. In my travels, I've met far too many people in the IT world who are slaves to their mobile devices — they don't like them, but feel like they need them. For my purposes, I've always just wanted a phone. A small, tough, easy to use phone. I never wanted a camera in it, I never used the date book or other little tools because, frankly, they were far more trouble then they were worth.

And though I must admit that I experienced a certain amount of techno-lust for the iPhone, I resisted buying one, mostly because I was under a contract with Verizon and I've been fairly happy with Verizon's service. If the iPhone had been available through Verizon, I suspect that I might have bought one the day they came out. As it was, that additional barrier allowed me to accomplish the herculean task of resisting its allure.

Last year, at WWDC, when Steve Jobs announced that sure, we developers all could write applications for the iPhone right away.... by creating web applications, I honestly felt like he had kicked me in the gut. Here, they  had created this amazing, possibly revolutionary new device, and they wouldn't give us developers an opportunity to really help them realize its potential. There was an audible groan when he made this announcement, something that rarely happens inside the RDF. 

Not too long afterwards, Apple started hinting that a real SDK might be forthcoming, and then later confirmed that it would be.

Needless to say, I have been awaiting Thursday's announcement very anxiously. This time, I was not disappointed. In fact, they exceeded my expectations: I ran right out after watching the videocast and bought myself an iPhone, downloaded the SDK, and started pouring through the pages and pages of really solid technical documentation already available from Apple.

And, though I can't tell you specifics because of the NDA, I can tell you that it is a thing of beauty. It really is. It is an elegant set of tools and libraries and I'm just giddy with excitement over this darn phone. I honestly think that the SDK has the possibility of completely changing people's perception of what a mobile device is, and what a mobile device can do. Some would argue that the iPhone has already done that, but I think the best is yet to come. I believe the iPhone can, and will, replace many special-purpose devices and become, as I heard one geek say, paraphrasing Tolkein, "the One Phone". Sure it was forged not in the fires of Mount Doom by Sauron, but rather in Cupertino by the will of Steve Jobs and the brains of an awful lot of very smart people, but I still think it's an apt analogy.

Several times a day a new idea will hit me for an iPhone app. I haven't been this excited since I discovered Cocoa / Objective C eight years go.

Japanese VS. iPhone

Japanese analysts are doubtful whether the iPhone will catch on in markets like Japan, where consumers favor smaller and sleeker multifunctional handsets. They also question whether Japanese carriers will accept ceding to Apple's tight control over handset design and agree to its demand for a certain share of subscription fees.

“Most Japanese consumers are more likely to remain content with what they already have” - said Nahoko Mitsuyama, a telecom analyst at Gartner Japan who attended the Mobile World Congress in Barcelona, Spain, in February.

However, Japanese analysts are doubtful. Current iPhones won't work in Japan, where the faster third-generation network has become the mainstream. Industry watchers believe 3G iPhones will be released in the latter half of this year.

Apple hopes to reach an agreement with a Japanese mobile phone operator to achieve its goal of selling 10 million iPhones worldwide by the end of 2008. It sold some 3.7 million iPhones throughout the world in 2007.

"Most of the world's Internet users via mobile phone are Japanese, so success in mobile services here can be applied to other markets."- said Noritaka Kobayashi, an information and communications consultant at Nomura Research Institute in Tokyo.

Japanese consumers are amazed by the iPod, which controls 54.5 percent of Japan's digital portable music player market - well above Sony's Walkman with 26.2 percent, according to market research firm BCN. The iPhone could benefit from an emotional attachment to Apple among Japanese.

"Japanese like anything new and trendy, so the thing is how many customers Apple can attract beyond Apple fans," - Gartner's Mitsuyama said, noting that Japanese on average change their handsets every two years.

Still, Japan is expected to be a difficult market. Here, mobile phone carriers control the release of new handsets and dictate specific features and functions of new cell phones to satisfy consumers who are picky about product usability, design and quality. Foreign makers account for only about 10 percent of the roughly 50 million handsets sold annually in Japan, although their market share is on the rise, according to Yano Research Institute.

Steve Jobs: Adobe Flash Will Not Be Supported By iPhone Anytime Soon

If you're enjoying watching the latest Flash videos on your iPhone, don't expect it anytime soon. On the shareholder meeting Apple CEO Steve Jobs said, that Adobe Flash will not be supported by iPhone anytime soon.

Steve Jobs claimed that the full-blown PC Flash version "performs too slow to be useful."

"There's this missing product in the middle. It just doesn't exist. Flash Lite is not capable of being used with the Web," declared Steve Jobs.

He said that the cause for that was Flash’s architectural limitation. This due to the fact that Flash was designed for PC, which has huge computing power. IPhone on the other hand has much less powerful CPU, memory, disk storage and battery.

Despite of Jobs announcement he insisted that Apple maintains a good relationship with Adobe all the same.

Flash on the iPhone:

Less technically inclined pundits have expected Apple to release a Flash plugin for the iPhone that works identically to the plugin used on desktop computers, similar to how the iPhone supports viewing PDF documents or Microsoft Word and Excel files. The problem is that the Flash runtime has never been designed to work on anything outside of a desktop computer, which has almost unlimited access to processing power and few constraints on battery use, available RAM, or heat dissipation.

The iPhone is a very different product. It's a fraction of the size of a laptop battery and uses a low power, embedded ARM processor that works unlike the Intel Core or PowerPC processors used in Macs and PCs that can run Flash. In order to develop a Flash plugin for the iPhone, Adobe's proprietary software would need to be recompiled and optimized for the ARM architecture, which isn't something Apple could easily do independent of Adobe.

Of course, some folks are likely to be more than disappointed with this announcement, some of them simply relieved that iPhones will remain clear of Flash's clutches, while others don’t even worry and think that there is no need of flashplayer on the iPhone as they will use computer if necessary.

References: AppleInder.com and ComputerWorld.com