iApps Development Blog

Samsung Galaxy Tab Advertising

Fri, 9 Sep 2011 13:42:03 -0700

I don’t really follow the Android world too closely. It kinda makes my head spin with the number of OS versions, gazillions of device models from a multitude of sources and carriers. The TV ads usually go in one eye and out the other. I’m glad no one asks me for Android device advice because I wouldn’t know where to begin.

A lot of promotional activity these days focuses on tablets that want to carve a slice of the iPad market pie. I do know that Samsung is a player in this space, and the company has been plastering the TV air and cablewaves with advertising that is supposed to make us all want one of their gizmos.

While watching some live TV last night (can’t skip over the ads, dammit), I saw one of the Samsung ads. Something looked a little weird to me, however. For most of the ad, the device’s bezel had an extraordinarily readable “SAMSUNG” logo on it. The logo didn’t look weird, necessarily, but the visual had a quality or size that made it look phony to me. Not imposterish phony, but Photoshop phony (or whatever program one uses to do CGI-like effects on video these days). Without the logo, the tablet being rotated and it’s-so-cool-excitedly manipulated by the human hands in the ad could have easily been mistaken for the tablet that almost everyone knows, the iPad (original recipe or 2). I wondered if the inclusion of the logo came as a post-production effect after Samsung’s ad agency ran tests of the ad, only to hear viewers thought the gizmo was an iPad. At the end of the ad, when they showed the devices in still frame, the logo was mysteriously absent from the devices, while it appeared clearly in text superimposed on the entire shot. Thus, Samsung was able (at last) to associate its identity with the device even if the device, itself, isn’t so labeled on the front.

(Now You See It)
(Now You Don’t)

It’s no mistake when a design is immediately identifiable through only a brief glimpse or even just a silhouette. Clayton Miller’s blog piece about the shape of different mobile OS app icons noted this a couple of months back. But the thickest connection to this concept hit me some years ago from watching The Simpsons DVD sets with the commentary tracks. One of Matt Groening’s precepts about character design is that the character should be identifiable just from a silhouette. That jagged flattop haircut of Bart’s is instantly recognizable, as are the outlines of all the main characters.

Has the iPad design become so identifiable with Apple’s brand that other makers have to go out of their way to distinguish their “wannabes” from the “is”? Maybe.

I visited the Samsung web site to see what the logo-on-bezel situation really is. I must have been napping the past few months because I discovered that Samsung talks about no fewer than three different models, each a different screen size. (“Oy!” my developer voice said.) Only one of them — not yet available from what I could tell — has the Samsung logo on the bezel. The others are logo-free.

Apple’s choice for its iOS devices is to place the company logo on the back of the device. A device’s user apparently already knows it’s from Apple, so let others who enviously watch the owner flip and tap and swipe his or her way to nirvana know who made the magical device.

Oh, and notice how the Apple logo is just a silhouette.

Location Tracking

Thu, 21 Apr 2011 10:00:14 -0700

Followers of my spamwars.com blog would probably rate me well above average on the privacy paranoia scale. At the same time, I know that unless you go completely off the grid with a hoard of cash stuffed in your sock, you leave more trails than a diarrheic rabbit.

Like plenty of other iPhone users, I checked out the quickie Mac app (iPhoneTracker), which reads the consolidated.db file that gets synced to your iTunes computer during a backup. Before I could even nuke a bag of popcorn, I had to hit the Play button to watch the movie of my life’s movements over the past 10-or-so months.

The story didn’t start out very well in the realism department. About the second week of the history, my iPhone supposedly spent a fair amount of time just northwest of Las Vegas. Not one hit around The Strip, mind you. But several along the US-95 and NV-157 roadways, frequently far from the hustle-bustle of...anybody. From the complete map, one would draw the conclusion that I spent the majority of iPhone-on time in Nevada, rather than the San Francisco area — where I actually spent the week. I haven’t been to Las Vegas in probably 10 years, and have never ever been as far north of the city as my rabbit trail indicated.

Then I checked the time period when I drove from the Bay Area to San Diego last September for iPhone DevCon. I drove the heavily-traveled I-5 route down the spine of California. There is excellent cell coverage the whole way, and it takes a number of hours to reach at least the L.A. area. Despite my round-trip ride, there were giant gaps in my trip record. It’s as though I had used a Star Trek transporter to get from San Jose to Santa Clarita because there was no evidence I had been anywhere in between. A snoop would also be hard-pressed to determine the freeways I took to get from downtown Los Angeles to San Diego because there isn’t a hit along the path until around Encinitas. Although I sailed through the area on my way down, I sat in a couple L.A. midday traffic jams on the way back — plenty of time to ping my phone.

I suppose my main beef with this whole tracking history isn’t that it’s happening behind my back. It’s that it isn’t accurate enough. How could I prove to my boss that I was in Sacramento to close the Thompson deal when my phone claims I was in Las Vegas? Yikes!

Is This For Real?

Wed, 9 Mar 2011 15:08:24 -0800

I normally cover suspicious email messages over at my spamwars.com site, but because the likely recipients to be taken in by the above email message are mobile developers, I’m talking about it here.

Several huge red flags waved vigorously when I first saw this message. To name the top ones:

✦ The To: field had an address I have never used to register anything with Microsoft.
✦ The message body is addressed to “Dear Sir or Madam”.
✦ The grammar (beginning with the very first sentence) is atrocious.
✦ The message text is actually an image file (and a .png at that). Those blue underscores are not separate links.
✦ The image in the message’s HTML is surrounded by a hyperlink tag that goes to a bing.com URL with many parameters.

But (and it’s a big but), according to the message header, it did, indeed, come to my server directly from a mail server in an IP block owned by Microsoft.

What you also don’t see is that the message came with a .wmz file, which is a compressed Windows Media Player skin file (under normal usage). The body of the message (that is, the body containing the image above) was generated with Microsoft word (oh, all that horrible XML markup...blech), and it’s possible that if the message is opened in an Office-compatible reader, the .wmz file would load. I ran the .wmz file through VirusTotal, and it found no matching signatures. There was a .wmz exploit in the Windows wild a few years ago, although it has long been patched.

Assuming that most recipients of this message to be tantalized by its content would be Mac users, I don’t believe the .wmz payload, even if nasty, is the primary goal of the sender. My attention is focused on the bing.com URL. Not being a Bing specialist, I don’t know what all the URL parameters signify. The field names for the visualsearch URL are: g, ve, qpvt, and FORM. Unfortunately I don’t have the time today to track down what these parameters mean. The goal of the sender, however, is to trick the recipient into clicking this link — made especially easy because the whole freaking email image is the active link. Thus, my suspicions lead me to believe this is a search engine optimization poisoning ploy.

The sourcing of the message from a Microsoft IP block is still a head-scratcher, unless someone’s PC up there has been compromised and has so far been undetected.

As is my usual response to any attempt to trick, I won’t play the game and click the link. I hope you’ll follow suit if you are confronted with this type of gimmick.

Ad Revenues

Mon, 1 Nov 2010 11:30:27 -0700

I released my PhotoSize app in late February 2010. It’s an extremely simple app, and I was amazed that no other product in the App Store fulfilled the need I had for creating it: Finding out the pixel dimensions of images after you’ve futzed with them in the tons of iPhone image editing apps out there.

At the time, the issue of how various image editors saved their images in shrunken proportions was a Big Deal to only a few iPhoneographers. The problem bit me in the ass when I submitted images to the first Pixels at an Exhibition, was honored to have two selected for the show, and went to the Berkeley gallery to see the prints produced by the organizer. One image looked horrible in print. Only later did I discover that one of the editors I had used had saved the results to an embarrassingly small size. Printing the result (and not even very big, mind you) was a disaster.

And so, one afternoon I spent some time in the iPhone SDK (as it was known way back then) and got the basic functionality for PhotoSize running in about 15 minutes. Plus another couple of days to build the rest of the app infrastructure around it (and generate an app icon that is straight out of 2nd grade). As useful as the app was (to me, anyway), I couldn’t bring myself to charge for something that I was able to throw together so quickly. Besides, there was no magic inside the app, and it could be knocked off in, well, about 15 minutes.

That led me to investigate placing banner ads in the otherwise sparsely-appointed app to supplement the revenue trickle from my other niche apps. Despite some glorious press reports from a few developers with mega hits, I had no illusions about generating huge amounts from ads. But if the app were sufficiently popular with iPhone photographers, it could conceivably buy me a cheeseburger.

I chose the AdMob platform. Although it wasn’t too long ago, I couldn’t tell you the precise reasoning behind that choice. It probably had to do with seeing a lot of other apps using that service, which (to my mind) meant that it was attracting enough advertisers to keep ads refreshed.

AdMob-enabled PhotoSize 1.0 went live on the App Store on February 24, 2010. I made sure that the app description clearly advised potential downloaders that it displayed banner ads. Of course, I also knew that a lot of customers never bother to read an app’s description, but there is only so much one can do.

Thanks to some publicity in Marty Yawnick’s Life In LoFi iPhoneography blog, the app had a decent send-off. Ad revenue, however, was pretty meager. That cheeseburger was going to have to come from McDonald’s value menu.

At WWDC 2010, I learned more about Apple’s own forthcoming iAds effort. I was more comfortable about the way one incorporated an iAd banner into a view, compared to AdMob’s approach. Plus, at the time Apple was rattling swords about using third-party advertising platforms. This was also while I was preparing a new release of the app to address a bug with humongo-sized images (which was going to snag the upcoming iPhone 4 camera images) and a problem imposed by the iPad’s OS 3.2 nightmarish implementation of UIImagePickerController. I used that opportunity to delete AdMob from the app and implant iAds in anticipation of the July opening of the service.

On June 28, 2010, I released PhotoSize 1.0.2 (having skipped 1.0.1), primed for iAds in iOS 4 devices, and all but ending AdMob revenue after a little more than four months.

That brings us to today, November 1, 2010 — four months after running iAd banners in iOS 4 devices (a.k.a., no retail iPads yet). Month-to-month downloads of the app have remained steady (but at a slightly higher average rate than the previous version). I won’t reveal numbers here, although I did lift the veil momentarily at a five-minute Lightning Talk at the recent (and great fun!) iPhone/iPad DevCon 2010 in San Diego. I wouldn’t call the app a runaway hit, but based on most review comments and emails I have received, a number of iPhone photographers and image editing types have found it helpful.

I’m also happy to report that revenue from the iAds effort for the same four-month time period has been literally three times that of the AdMob deployment.

Beneath the revenue numbers are some even more interesting supporting figures for the number of requests, impressions, and click-through rates. AdMob was obviously in full swing by the time I got around to inserting their ads in my app, while iAds had a well-publicized slow ramp up (few advertisers, many requests going unfilled, etc.). Given the four-month spans of both efforts, the number of requests was larger during the iAd reign — a continually growing installed base must have helped that along. In contrast, AdMob reported a far greater number of impressions, and the click-through rate was almost three times as high as iAds. Yet iAd revenue to me was three times the AdMob revenue. If your app has broader appeal and bigger download numbers than PhotoSize, then this should get your attention.

Additionally, iAd revenue is lumped into the monthly payments I receive for paid apps. Compare that against the one check I received from AdMob in August.

Bottom line: I’m a happy camper with my choice of iAds for the free app’s banner ads. I have enough now for gourmet cheeseburgers for myself and a couple friends.

My Policy on UDIDs

Tue, 5 Oct 2010 12:26:53 -0700

There have been several reports circulating that a lot of iOS apps apparently grab your device’s unique identifying number, and silently send that number to the developer. You can see that number for yourself, by the way. When you connect your device to your computer and view the device in iTunes, the Summary screen shows the serial number. Click on the serial number, and the display changes to the UDID: one humongous hexadecimal number.

If you are asked by a developer to be a pre-release beta tester, the developer will ask you for your UDID. The number is necessary for the beta copy to be installable on your test device.

A UDID contains no personal information. Only Apple, any developers for whom you test iOS apps, and probably your carrier could link the device’s UDID to you as a person. Still, many users would find it creepy that a developer is “watching” your installation and perhaps usage of his or her app that you have downloaded from the App Store.

As a big proponent of Internet privacy I don’t like anything on a computing device sending stuff without my permission or knowledge. As it happens, I also believe in the Golden Rule, which is good for users of my apps: because I don’t want apps sending stuff without my knowledge, I have built all of my apps to behave in that manner. Therefore, for the record, none of my iOS apps are designed to send UDIDs or any other usage info to me or third parties on my behalf.