Tag Archives: marketing

Post navigation

If you still use launch screens, these are the sizes you need.

As with mobile icons, the proliferation of new Apple mobile devices demands an ever increasing number of launch images. This post lists the necessary artwork sizes to directly support all devices (and possible orientations) as of iOS 12.

Of course, Apple realizes that adding new launch screen sizes every time they introduce a new form factor will quickly become unsustainable. (It is close to that now; otherwise, this post would be unnecessary. 😉 ) For that reason, they introduced launch storyboards, which allow a launch screen to be defined by a layout of controls and constraints, rather than by individually sized images. The only problem is that, unlike normal storyboards, the launch storyboard is loaded before the application runs, so only automatic layout can occur; no code can be executed. Therefore, customization is restricted, which prevents developers from accomplishing the same thing that is possible with launch images, namely, use of the entire screen on each individual device for displaying an image.

Apple takes the position that the launch screen should display an image reflective of the first screen of the application to give the impression that the app has launched that quickly. This certainly is better for Apple, who is not known for missing branding opportunities, but using the launch images for branding, i.e., a splash screen, is expected in the game industry (and, arguably, for any software). Also, games usually have custom background artwork, and if that is customized to screen sizes, there is no easy way to mimic that with a launch storyboard, at least at the moment.

To be fair, nowadays the launch screen is a somewhat rare occurrence, as it is only shown at first launch, or when the application has been unloaded, either closed by the user or removed from the background by the system to recover resources. If you design your splash screen to be an image in a sea of solid color or a repeating texture, you can reproduce that with a launch storyboard. The kind of splash screens that Rick Tumanis designed for Demolish! Pairs or Pretty Good Solitaire, however, do not lend themselves to this approach. It is for that reason that we still use launch images in those games (and others). In fact, Demolish! Pairs will reshow the splash screen if you shake the device from the menu. (It is an ‘undo’ when done from within a game.)

So without further ado…

iPhone Launch Screen Sizes

Apple iPhones provide the bulk of the variety in device screen sizes, so you need to provide 11 (or 12) launch images for full coverage, as follows:

Note that the lowest supported target system for Xcode 10.0 (latest version as of this writing) is iOS 8.0, and no devices at the original iPhone resolution (320 x 640) can run that version of iOS, so the final unique size (#12) is unused in modern apps.

iPad Launch Screen Sizes

There is good news and bad news when it comes to supporting iPad launch images.

Good News

The good news is that you only need 4 launch images for iPad support, as follows:

That is pretty straightforward, especially given that they are the same aspect ratio, so you can just create the double density size and directly reduce the image. Further, if your target platform is iOS 10 or higher, the iPad 2 is no longer supported, so you only need the two larger images for all remaining iPads.

For completeness, here are the legacy sizes for iPads running iOS 5 or 6:

iPad Portrait Without Status Bar iOS 5, 6 (legacy)

768 x 1004 – 1x (optional – unused on iOS 8+)

536 x 2008 (@2x) – 2x (optional – unused on iOS 8+)

iPad Portrait iOS 5, 6 (legacy)

768 x 1024 – 1x (same as #1)

1536 x 2048 (@2x) – 2x (same as #2)

iPad Landscape Without Status Bar iOS 5, 6 (legacy)

1024 x 748 – 1x (optional – unused on iOS 8+)

2048 x 1496 (@2x) – 2x (optional – unused on iOS 8+)

iPad Landscape iOS 5, 6 (legacy)

1024 x 768 – 1x (same as #3)

2048 x 1536 (@2x) – 2x (same as #4)

The only (4) new sizes here are just the same launch screen sizes with an area for the status bar (20 or 40 pixels) removed. These sizes are never used in modern apps.

Bad News

The bad news is that, as keen observers will have noticed, I did not list any of the iPad Pro models above; this is because an iPad Pro acts like an iPad Retina. Without a launch storyboard, all iPad Pro devices show up as though they are only 2048 x 1536 resolution.

To be fair, the smallest iPad Pro, the 9.7″ model, is only 2048 x 1536, but the two larger models have higher resolution that is not used: 12.9″ is 2732 x 2048; 10.5″ is 2224 x 1668.

If you want to have the full resolution of iPad Pro devices, you must use a launch storyboard rather than launch images; you cannot use both, as (experimentation suggests that) the inclusion of a launch storyboard supersedes launch images. Damn.

Conclusion

The release of iOS 12 added the need for 4 additional launch screens (to support both orientations for the iPhone XR and iPhone XS Max), so a “universal” app needs to provide a total of 15 launch images to support all iPhone and iPad devices. However, if your game or app needs to take advantage of the full resolution of the iPad Pro, you will need to provide a launch storyboard instead, and adjust your launch screen appropriately.

All Apple needs to do to provide complete support is to provide constraints for individual form factors, allowing different images to be selected from the launch storyboard based on device model, OR use a provided launch image in preference to (or prior to) a launch storyboard. Best of all, they could just remove the arbitrary and silly restriction that prevents access to full iPad Pro resolution unless we provide a launch storyboard, which restriction seems to be in place for the sole purpose of strong-arming developers into supporting launch storyboards (before they provide equivalent functionality).

In the meantime (which will likely be forever), it makes sense to start figuring out how to adjust your launch design and strategy to work with launch storyboards. This is not unlike what is currently necessary for Android support, anyway. For our next project, we are investigating a high resolution square-ish logo that can be the sole image in a field of white, scaled to largest size possible to fit the launch screen.

Adding SSL/HTTPS support to Apache.

You may have noticed (or not) that this blog has recently acquired a little padlock icon to indicate that it is “secure”. You can now access the blog using “https://”; in fact, using “http://” (without the ‘s’) just redirects to the secure page anyway.

Marketing Purpose

This change has been on the task list for a very long time, but it finally became really important when, last July, Google changed Chrome to display “Not secure” next to any web site that did not have a certificate. Given that Chrome now represents about 60% of browser usage across all platforms, that is not an audience we would ignore.
Fortunately, at the moment, the little indicator in Chrome, and other small reminders in various browsers, are not too damaging, but this is likely just the beginning of more and more dire warnings. Realistically, there is essentially nothing passed from this blog outside of Digital Gamecraft itself that needs to be encrypted, per se, but readers do not necessarily know that, and they should not be asked to know that, either.
From a marketing standpoint, anything that causes a “customer” (in this case, reader) to have to make a decision (e.g., “Is this site safe?“) reduces the likelihood that individual will continue, which means that it reduces the audience. Not desirable.

Technical Purpose

In the past (i.e., when this task was first added to the web improvements list), adding support for secure, encrypted communication via SSL/TLS/HTTPS was a complicated and confusing process. Frankly, this is why it never quite bubbled up to the top of the list and, thus, never got implemented until recently.
Without getting too technical (because I could not, even if I wanted to), SSL stands for Secure Socket Layer, which is a protocol for encrypting communications, and TLS stands for Transport Layer Security, which is a newer version of the same thing. TLS actually supersedes SSL, but the latter is still used generally to represent both SSL and TLS. HTTPS is the protocol used to do the actual communication.
The idea is that everything transmitted over the internet (such as this blog post), if not encrypted (i.e., using HTTP), is readable at every server and router along the way. Encrypting the data makes this (nearly) impossible, so TLS (or SSL) is used, and HTTPS tells the receiving computer that the message needs to be decrypted. The process of encrypting and decrypting data relies on certificates that need to be obtained from a certificate authority (CA), which is where things were most complicated.
In the “old days” (just a few years ago), you would have to contact a CA to get a certificate, and this process often required providing lots of information to prove who you were before (always) paying an annual fee for a certificate. There are different types of certificates with various levels of verification and you can still spend upwards of $500/year on a certificate, or even $150/year or so for certificates no better than certificates you can get for free.

Implementation

You read me correctly: FREE. Over the past few years, the cost of low-end certificates (enough to be considered “secure”) has dropped to the point of now being free and automated. In particular, Let’s Encrypt is a certificate authority “run for the public’s benefit” that provides free certificates.
Additionally, the automation provided by Let’s Encrypt and EFF’s Certbot makes this fairly simple to do. After the fact, knowing how easy this was, I am somewhat embarrassed that I did not do it sooner. So, here is how I did it…
I started at the Let’s Encrypt site, read a little bit, and then was directed to the Certbot site, which (on the main page) just asks for your web server and system type. Caveat: We run our own servers here, so I have full shell access to the system; I do not know how much more difficult it may be trying to do this through a web interface.
Because we are using Apache running on Ubuntu (Xenial) to serve this site, I ended up on this Certbot page. First, I updated my system, just to start with the latest components, and then I just followed the (5) steps in the Install section. If you have ever installed Linux software from a command line, the process should seem quite familiar.
Next, I typed in the first command under Get Started:

sudo certbot --apache

I answered the few questions (asked only once) about, as I recall, contact information and whether I wanted to be added to the EFF mailing list (emphatically not). The meat of the program produces a list of domains served by the Apache installation and allows you to select which ones you want to serve as HTTPS. After that, it asks whether you want to redirect all HTTP traffic to HTTPS (recommended), which seems to be working flawlessly.
In our case, we have quite a few domain and host names all serving one of a relatively small number of sites. I initially did just one site (https://sophsoft.com), which worked a charm, but I ended up recreating that certificate and including all of the other host names that serve up the same pages (e.g., www.sophsoft.com and sophsoft.info). I then repeated the process separately for each discrete site. Voila! Done.
Actually, the installation process, when finished, gives you a link to SSL Labs testing page so you can verify the security of your page. All of our pages were given Overall Rating: A.
As noted in the Automating renewal section, the certificates are only good for 90 days (gift horse and all that), but it looks like there is a cron job that can be installed to automatically renew. I admit that, until I started writing this paragraph, I thought that it had been installed already, but it looks like I will need to do that myself.

Final Adjustments

We did still have one or two pages (OK, the whole blog 🙁 ) that initially served up encrypted pages but still showed a broken padlock, indicating lack of security. This can be caused by residual HTTP references in a page, which result in only portions of a page being secure. Often, image links are still insecure, so they need to be fixed.
In our case, the blog needed the canonical address to be updated to HTTPS in the settings, the custom theme had a reference to an image file accessed insecurely, and many of my actual blog posts made explicit HTTP image references. It really only took a few minutes to find and fix the issues, but there was a little sleuthing involved.

Conclusion

Sooner or later, and I imagine sooner, web pages that are served up without encryption will be the outliers and will have an increasingly diminished reputation. I would be quite surprised if Google’s search ranking algorithms did not already favor HTTPS pages. Given that the cost has now dropped to nothing and automation makes the process pretty easy, it seems like an obvious improvement for any business that values its web presence.

SophSoft, Incorporated jumps back into the fray.

After a respectful (and necessary) period of readjustment, while SophSoft, Incorporated and Digital Gamecraft™ added a second office on the west coast, we are making our public reappearance.

It has, admittedly, been a while since I have made any concerted effort to market our development services or published games, or to comment on industry events. Instead, I have retrenched to focus on our core concerns: key clients, business organization, and (of course) financial stability. Having made significant progress on all fronts, it was time for us to again perform those functions that go beyond simple maintenance to actually growing the company. To that end, I am not only committing time to this effort but getting more assistance in areas that I can efficiently delegate.

Here is a quick roundup of the news (past and upcoming):

SophSoft, Incorporated

Over the past year, we have continued our previous development work, most notably for Goodsol Development, with whom we have been working for 15 years (later this month); there have been several releases in that time, and many more are still scheduled to be shipped (for Windows, Mac OS X, and iOS) during the rest of 2016.

We have added to our collection of mobile devices (iOS, Android, and Windows) for development and testing, as we have continued to improve our knowledge and experience on all three platforms. (I can neither confirm nor deny reports that Apple Watch, Android Wear, Apple TV, and Android TV are included in our forthcoming lineup.)

As a departure from games, development is underway on a new line of productivity tools that aim not only to enhance our bottom line, but also (actually, primarily) to significantly increase our internal efficiency and organization.

Digital Gamecraft

We have continued to support (albeit not promote) Demolish! Pairs for iOS, while we have been making progress on an Android edition. This progress on a new platform for Demolish! Pairs has gone from fitful to steady, and it is now increasing in velocity. We have some new marketing prepared, including an online playable version (in HTML5). Expect new features and new platform announcements fairly soon.

In addition to that title, our next game is already under development. This one will be the first of our “Gamecraft Classics™” series of classic board and card games, and it represents an early step along our roadmap of upcoming titles in five major genres, as well as a few experimental (‘one off’) titles. All of these games feed into our SophPlay™ System for robust game development, strengthening its foundation.

Finally, plans are in place for renewing and enhancing our presence on social media, expanding from Facebook, Twitter, and Google+ into more places for community. Follow us via these links now and experience the resurgence as it happens.

Still More…

As noted, we now have offices in both East Lansing, MI and Los Angeles, CA, and it has been a chore getting our infrastructure working (together) in both places. Now that we have stability, we are enhancing our capabilities with new, faster servers. Although the switch-over and retirement of older hardware is still in progress, users should experience more responsiveness and better reliability (if not now, then within a couple of weeks).

As ‘no battle plan ever survives contact with the enemy‘ (in this case, the challenges of limited resources and product discoverability, primarily), there is no doubt that our goals are ambitious and our priorities will change. However, as an entrepreneur, I find that merely maintaining the status quo is more stressful than risking failure.

You have a game idea. Let us create it for you.

This week marks 20 years (!) since we first took our company full-time. In that time, we have developed more than 25 products for a variety of clients. We have published games for Windows, Mac OS X, and iOS, and we have extensive experience.

Now, we are available immediately for new development contracts. We have a significant opening in our schedule, which we need to fill soon. This is your chance to have a world-class game developer working (or consulting) on your project. If you want to explore this opportunity, please contact me directly at seelhoff@sophsoft.com.

Today is the BIG DAY of this important conference.

Mobile games may not play by the same rules.

We have now entered summer (in the Northern Hemisphere, anyway), which is traditionally a slow time for sales in the game industry. The explanation over the years has generally been that this is a time during which people take vacations and spend more time outside, so they spend less time at the computer or game system and play fewer games. This certainly makes sense for desktop and console games, but in this day of increased use of mobile devices and handhelds, the traditional explanation may not hold (as much) water. When one of your game systems (i.e., phone) travels with you everywhere, it makes sense that it would get used as much as usual; in fact, it is likely used more in places like airports, the back seat of a car during a long drive, and the hotel room after the swimming pool has closed for the evening.

Of course, if summer shifts play to mobile games, where the (dubious) profits are marginal, at best, this is still likely to result in an overall slump for companies who support more than one type of platform. Nevertheless, I expect that consumer behavior changes differently in the summer with respect to mobile games. I would hope for extra game purchases in preparation for a vacation or while waiting during travel.

Interestingly, our limited data (with a little squinting 🙂 ) can fit that scenario. Since the holiday weekend at the end of May (Memorial Day in the United States, Late Spring Bank Holiday in the UK), downloads have changed. At the start of that weekend, we saw a spike in downloads which mostly persisted through the (holiday) Monday, after which they essentially flatlined for a few days. Then, last weekend, we had another (smaller) spike on Friday, Saturday, and Sunday, then (now) back to zip. Alas, our total download counts are too small to draw definitive conclusions (or even be statistically significant 🙁 ), and it has only been a couple of weekends. (Our sales do not definitively correlate with downloads.) Also, many schools around here are still in session, so we are not really into the heart of summer vacation season either, though the weather is definitely much improved.

Operating more on the assumption that mobile sales may persist through the summer, and the knowledge that sales really need to improve, than on the need for experimental data, we have decided to put Demolish! Pairs on sale for 50% off throughout the month of June, and we have likewise discounted all IAP products in Demolish! Pairs FTP similarly. Sure, it may skew the data, but in a good way. 🙂

As a reward for reading this blog post (assuming that you have done so in a timely manner), I will tell you that we are approaching the 1 year anniversary of the Demolish! Pairs release, and to celebrate, we plan to make the game absolutely free for one day only, on June 18, 2014. You can download the game on that day (two weeks from today) and keep it forever.

Our game development consulting site is back online.

Historically, this site has been the main web site for SophSoft, Incorporated, our parent company. We have had and used the domain name since November 14, 1995, and the official corporate name was, in fact, taken from the domain name.

The site has been down for a while, though. Honestly, we found ourselves in a bit of a weird and unfortunate situation. When our business partner and artist, Rick Tumanis, died back in 2011, it was a huge loss. Not only did we need to regroup from the sadness, but we also no longer had our Art Director to draw upon. This meant both that the services we offered would need to change and that the person in charge of web design and appearance was, shall we say, unavailable.

After more than two and half years, with the site having been pulled when we replaced a web server quite a while ago, I finally made the move and built the new (albeit small) site and published it for those who have been looking for our game development services. I kept a few items from Rick on there, but realigned the focus. At some point, I will add pages specific to our various contracting projects, but for now, the site is back.

If you need game development assistance, either with technical programming challenges or with higher level management and design, or want to have an entire game created by a professional team with decades of experience, be sure to check out SophSoft.

Results show few opportunities for optimism.

When I wrote an earlier blog post, FTP: Early Results, I stated that it was too early to draw any conclusions from the very early data from Demolish! Pairs FTP. However, now that we have almost two weeks of data from Demolish! Pairs FTP on the App Store, the results are beginning to look more conclusive.

Day-to-Day Play-by-Play

Here is a rundown of the basic results since the app has been available:

Day 1: [baseline]

As previously reported, the first full day of downloads was Thursday, November 7, 2013, which provided more downloads, from 24 different countries, than we had sales of the “paid” version, Demolish! Pairs; therefore, I will use that number as the baseline figure for downloads (i.e., 100%) and all other percentages are relative to this figure.

Day 2:

On the second day, we did not do any additional marketing in order to determine the approximate natural fall off. The icon was no longer visible on either of the game category pages (and certainly not on the main game page). Downloads were at 72%.

Day 3:

We announced the release (again) on the Digital Gamecraft page on Facebook, this time using ‘Boost Post’ to promote the message to two countries, the United States (our biggest market) and Australia (an unrepresented English-speaking market). For $51.69, we “reached” 30848 Facebook users. Downloads: 64% (none from Australia)

Day 4:

We stopped the Facebook post promotion and allowed for residual effects to accrue, which they did by virtue of Australian downloads outpacing US by one. Downloads: 37%

Day 5:

This time, we tried a targeted Facebook ad, selecting for puzzle game players, in (6) English-speaking countries, who used iPads. (Oddly, I could not find a way to target only mobile users, so some views would be on desktop systems. 🙁 ) Facebook reports our total reach to be 50541 (about 3% of the selected audience). Downloads: 20%

Day 6:

After stopping this latest Facebook ad, there was an unexplained “blip” in the results, which could have been a residual effect. Downloads: 27%

Day 7:

With the slight increase in downloads on Day 6 (and, frankly, with other priority tasks), we decided to wait another day to see if the upward trend would hold. Unfortunately, downloads plummeted to the worst level yet: Downloads: 4%

Days 8 through 12:

Risking “zombification”, we left the game alone to simply observe. It continues to draw low levels of daily activity. Downloads: 4%, 3%, 6%, 4%, 2%

Three Strikes

Clearly, the download figures were destined to drop toward a minimal level, with the Facebook marketing making no discernible difference. However, there are three worse facts that make a big difference here.

First, although the number of iAd requests climbs steadily, the number of ad impressions is phenomenally low (as the fill rate remains below 3%), so advertising revenue is essentially non-existent; it has not yet eclipsed the $1 mark (total).

Second, despite the number of downloads, nobody has purchased any IAP product at all. The game is being played, as shown by the iAd requests, but the conversion rate is 0.0% as everybody plays only for free.

Third, the existence of a free-to-play version has cannibalized “paid” sales. Not only is nobody paying for any IAP, but sales of the original edition dropped to zero when the FTP edition was released, and it has not sold a single unit since.

Conclusions

Although I still have some things to try yet, my recommendation to anybody considering the mobile games market is not to waste any time on it. In fact, I would suggest that anybody who is looking to begin a career in game development right now strongly consider a different line of work entirely.

Note: This is blog post number 405, which is the HTTP status code for “Method Not Allowed“. Coincidence? You decide.

Problems with our free-to-play design emerged.

As we analyze the results of Demolish! Pairs FTP, the free-to-play edition of our fun arcade/puzzle game, Demolish! Pairs, this is good time to review the basic design of the IAP (In-App Purchase) products and other options we provide for continuing play.

The Original Design

The first complete plan included the following four IAP products:

Golden Ticket [$3.99] – This product permanently removes all game restrictions and all advertising, providing the same unlimited experience as the “paid” version.

Two Day Pass [$0.99] – This product would offer a 48-hour subscription, or a 48-hour extension to a subscription, with no limits or ads.

As we considered the various views that might be necessary to provide notifications of game limits, as well as how we would offer products to eliminate ads, it became clear that one unified store view, which doubles as a notification message, would serve the purpose nicely. (We plan to refine this idea further.)

Additionally, we added the idea of a button to extend play, for free, which can only be used once each 12 hours. In practice, we implemented the countdown timer to only begin at the next restriction notification, to make the idea of “appointment” gaming work for us more clearly. We also limited the extension to the current game (for each player).

The First Hurdle

In an earlier post, Free-to-Play Take 1: Rejected, I documented the initial rejection of Demolish! Pairs FTP due to the fact that the 48-hour subscription was against App Store guidelines, which require all subscriptions to be at least one week.

The original IAP was designed together, as a unit, so each of the buttons would function in conjunction with the others to create the desired “menu” of offerings. The most expensive (read: still really inexpensive) option was deliberately the same price as the original (“paid”) edition. The crucial part was to have a cheap option, at only 99 cents, which provided some value, and then another option at each pricing tier. Once a player commits (mentally) to spending (less than) a dollar, it is only another buck to reach another level of value, and again and again, up to having it all for only $4. A customer can purchase a middle level of value (Silver Pass or Express Pass) and then, later, obtain the equivalent of a Golden Ticket by purchasing the other one, but the ultimate price difference ($0.99) is the incentive to go for it all at once.

When the lowest tier caused rejection of the game, we quickly removed it, accepting that this destroyed the carefully considered equilibrium of the menu of purchase options. Also, because of simple mathematics, we could not drop prices and make it work correctly. We have now designed a replacement (non-subscription) product to provide that least expensive option, though that will take a little more implementation time.

The iAd Problem

As mentioned my last post, FTP: Early Results, the only thing that was absolutely wrong was that iAd had not started serving any ads, so that completely messed up the IAP design. The Express Pass was pointless, and even looked like some kind of idiocy, because there were no ads to remove in the first place. On top of that, of course, that also relegated the Golden Ticket to the same value as the Silver Pass, so essentially our whole menu of IAP products had been reduced to merely one logical choice.

Two or three hours after I posted that article, iAd suddenly began serving some ads. I actually discovered it while playing the game on my iPad just for fun and, unexpectedly, getting an advertisement for Small Business Saturday, after which I was able to confirm a handful of ad impressions (for thousands of requests). I had never been so excited to see an online ad, and it briefly looked better.

Unfortunately, though ads are being served occasionally, the fill rate is still far below 4% (i.e., 1 ad for every 25 requests), which is almost worse. Now, the very irregular ad appearances make them almost novel, so there is no real incentive for an Express Pass (nor for choosing a Golden Ticket over a Silver Pass), and there is no indication that the fill rate is going to improve substantially. As an unexpected twist, most of the few ads that do show up look fine and unobtrusive; in fact, the blue and gold of the most common banner, from Progressive Insurance, almost matches our menu color scheme exactly.

The Next Step

Our next step will be analyzing customer behaviors to see if we can glean any useful information from the limited number of downloads so far. We have a custom analytics package (that I developed) built into the app but we were waiting to see how the initial release progressed before “flipping the switch” to begin actual reporting. It now seems fairly clear that our server will not be overwhelmed…

In a word: Inauspicious. 🙁

On Wednesday, Demolish! Pairs FTP was released on the App Store. Here are the initial results for this launch, keeping in mind that, so far, it has been fairly low key to remain in line with the initial launch of Demolish! Pairs to allow a comparison between “paid” and “free-to-play” editions.

Day 0: partial day

The app was first available on the (US) App Store shortly after 5:00pm EST, and it became searchable/discoverable about a hour later. Therefore, the results, which are reported around 7:00am the next morning, represent only a partial day. I am not sure when a “day” actually ends in Apple-land, but I assume it is around midnight in the Pacific time zone (3:00am here), so this data probably represents about a third of a full day. Also, this also means that the release only hit part of the globe in prime app time.

That last part proved particularly true, as alldownloads for the first (partial) day were from only two countries, the United States and Mexico. Interestingly, and disappointingly, when compared to first day sales of the “paid” edition (at $1.99 each), free downloads only exceeded this figure by ONE. This is, of course, an apple and oranges comparison, but I still would have expected more downloads.

One primary reason for the low download count was the huge number of “free” releases every day (even relative to paid submissions), so while Demolish! Pairs FTP was on the category front pages, it was beyond the “fold”, so users would have to scroll right to even see the icon. I also discovered that, unfairly, the free releases are not put in chronological order, but alphabetical order, so beginning with D put us off the visible part of the main page, and the poor bastards whose apps start with I through Z never have them appear on the front page at all. This meant that, while the “paid” version had a couple of days visible on the main category page, the FTP edition never had that at all, and partway through day 1, it was swept off the page entirely by the next group of freebees.

Day 1: first full day

As stated, day 1 (Thursday) was the first full day of downloads, and things looked a little bit better. The first indication, via hourly iAd updates, was that the number of countries requesting ads went up significantly throughout the day. When the final results came in, there were downloads from 24 countries, which exactly matched the iAd country count (though, oddly, iAd also had a few “unknown” requests).

In sheer numbers, downloads for the second (first full) day were up 544%, which was more than double the expectations if day 0 were 8 hours (and downloads were level), so the trend is positive. Also positive (I guess 🙂 ) is that the number of day 1 downloads exceeded total (lifetime) purchases of the “paid” version, which means that our free-to-play edition is now in more hands than the original (and, as iAd shows us, almost all of them have been played, not merely downloaded).

Now the Bad News: I have not mentioned IAP sales because, thus far, they equal precisely $0.00, so our game is being played more, but nobody has paid us anything. Of course, some of the incentives may take a while to work, so I am not jumping to conclusions yet. Not at all unrelated (as a causal factor) is the fact that iAd has received thousands of ad requests yet has served exactly 0 ads. None. Nada. Not one. I have lots of strong words and strong feelings about this, but I will compose them (and myself) in my next post.

Conclusion

It is actually far too early for any conclusions (except that the iAd 0.00% fill rate is a major problem), but the data is enough to decide to delay the next marketing step for at least one more day, to see what kind of falloff we get for a full day with Demolish! Pairs FTP not on the front pages of each category. After that, experimentation continues!