©ompass360° (augmented reality) 1.0.0 - Marketing thoughts

Share on Twitter Share on Facebook

I wondered if there is any sesnse of a facebook advertising campaign. Since a facebook campaign produces only visitors to the product page, I have to estimate somehow the "efficiency" of the product site, or can say how many visits ends up in "shopping" the application.

It seems easy at a glance. I have to compare my google analytics report to my iTunes Connect reports. But there are "native" buys caused only by browsing the App Store.

Fortunately I have some data collected from ©TapStack survey that asks users about where from the heard about ©TapStack. The Forum promoted surveys gave that only 9% of the users heard about it from App Store. But the In-App promoted survey gave that 38% of the users (they have the application right on their device) heard about ©TapStack from just browsing the App Store. For this estimating process let say that 25% (the quarter) of the shoppings are from "native" App Store browse/search. Every other shoppings are from other promotion sources (its the product page for now).

Now let me compare the site visits to the shoppings. If I see the raw visitor data along with the downloads, there is too much "spread" can be experienced. But if I focus on particular countries, then the visits and the downloads draws the rule. Almost every targeted visit (referred from a forum post, or from my blog) resulted in a shopping.

So we can say that visits results at least a 70% shopping. One visit carries 0.7 "shopping will". That seems a realistic estimated value (for now, later it can be changed of course, i have to monitor this rate continuously).

So as long as the price is $0.99 (with $0.7 USD royalty), one visit means $0.49 for me, so any visitor who "cost" less than $0.49 can be profitable for me (that means I could pay half a buck for every Ad click).

Now let see the inverse. Let say I pay $0.1 for every Ad click. Then until only one visit produces shopping ouf of every 7 visits, the advertising campaign is still at a zero balance. That would mean that the product page needs to produce only at least 14% shopping will. As long as this rate is above 14%, the advertising campaign is "profit-safe" (with this 10 cent per click budget).

Furthermore, one point is important, is the "quality" of the visitor. If there would be too many referring page to the product site, then it would redirect many people less interested in this ©ompass stuff. So the point is to promote the page only where the people may be interested the best, or can say the promotions have to be targeted, and this is what a Facebook advertising campaign can do.

So the "less but interested" people to reach could be more efficient than reach millions, and pay for "bounce" visits.

Another point is that even if the campaign ends up zero balance, the application downloads could still affect the App Store rank, and that could produce even more "native" shopping.

All in all, I'll submit this Facebook Ad, then keep tracking all the stats (Facebook Ad, Google Analitycs, iTunes Connect).

©ompass360° (augmented reality) 1.0.0 - Released

Share on Twitter Share on Facebook

At last! The application has released while I spent my vacation, so now anyone can find it in the App Store - ©ompass360° (augmented reality) 1.0.0.

Ya should wait for a free promo code to be twitted @compactApps, or buy it while its at the introductory (50% off) price. The product site has also finalized, should take a look on it at compactapps.eu.

©ompass360° (augmented reality) 1.0.0 - still shaping product site

Share on Twitter Share on Facebook

This is something I can love more (it has 4 more slides). I have to write some headlines, then it can be released.

©ompass360° (augmented reality) 1.0.0 - memory problems

Share on Twitter Share on Facebook

I decided to reject my current binary.  I've four days lost in the review queue, but I think it is worth.

As I tested ©ompass360° under different circumstances, I experienced that there are cases, when it receives a memory warning, then the OS terminates it (without even finish the launching process). The situation came up when about 12-16 other application ran in the background (with kinda intermediate memory consumption).

I  played around with handling memory warnings (or measure free memory before I allocate anything) to alert user to consider quit some background tasks, but at the end I realized that is not too iPhoney approach (most of the users never cares about multitasking at all, I think). All in all, I decided to trade that 6 megs of memory to that image quality. Since then the application never gets terminated even if more than 40 apps run in the background, and I am happy.

As Mike Weller pointed out at stackoverflow.com iOS terminates applications in the background if the foreground process needs some space. And the key thing was that he said iOS terminates the most memory heavy ones. So I don't want that bounty on my application's head.

Back to the product page.

©ompass360° (augmented reality) 1.0.0 - shaping product site

Share on Twitter Share on Facebook

Without any further comments, let stand here the work-in states of the product site layouts. Something really clean/premium, and of course "outdoory" in a way.

The scenes behind the descriptive fields gonna be act as a slideshow, as I planned. Maybe there could be some kind of help, or at least some "manual"-like section where I write something about the heading calculations. Maybe not.

©ompass360° (augmented reality) 1.0.0 - appstore submission

Share on Twitter Share on Facebook

Yesterday I submitted the binary to the App Store. Made some screenshots with the national parks/seas in the background, created the icon mutations, and wrote something about the application.

Made an iPhone App Store preview to see if there's anything missing. Maybe the Augmented Reality feature is not weighted enough.

Update: since then I updated the name to ©ompass360° (augmented reality) just as the title goes.

AppStore preview of ©ompass360° (by the way, introductory price gonna be 0.99 USD).

Now I have to do something with the product site (and set up a twitter account for compactApps). I have not the domain at all yet, so it runs under compactgames.eu - http://www.compactgames.eu/compactapps.eu/ - at the moment. Something "outdoory" gonna be there.

©ompass360° (augmented reality) 0.9.9 - a new feature born

Share on Twitter Share on Facebook

As I tried to calculate the 3D heading values, I realized that these values "works" only when iPhone is vertical, or can say when its not lie horizontal. So I have to implement two ways of calculating heading values.

The classic heading calculation is came from CLLocationManager's heading value. It is based on the axis that goes upward from iPhone's center (to the headphones). Every heading calculations is based on this axis. Therefore as you rotate to landscape, the axis will rotate too. So a North (0°) in portrait mode shows West (270°) in ladscape mode. So this value just cannot displayed as a heading in this 3D compass.

So the value I need is something that is connected to - even calculated from - this Augmented Reality space. After some brainstorm I realized that I need the camera lens axis' angle from north to determine this 3D- (or can say camera-) heading. But note here that this value just cannot be measured when the phone lies horizontal (I can measure the angle between the magnetometer projection vector and the lens axis projection vector on a horizontal plane).

So I have these features, and so a new preferences button. The user have to decide that he wants to use the 3D- (camera-, real-, actual-) heading values, or the classic (flat-, portrait-, 3D-, device-) heading values.

Maybe I can merge a third option as Auto that can decide when to use which, but I think it is... ...Hey! It is important! "Novice" users just cannot decide when to use which, but I have to get my application work under any circumstances. Furthermore, Auto has to be the default value (or maybe the only one)!

There is a little optimization with classic mode, since it don't measure upside down when the device is upside down (when pitch angle is less than -45 degrees relative to vertical), I have to flip it back.

So there need events with respect to the devices pitch angle. I have to go to classic heading when the device is (or close to) horizontal in Auto mode, and have to flip classic values when the phone is upside down (or face down as they say).

Therefore I have to "monitor" somehow which mode is active. I implemented the calculations already, and merged a dotted line to the screen that shows the heading measure axis, but there could be some kind of icon as well, and somethin' borderline in the compass texture that shows the "mode" ranges.

So the implementation of the last feature is to be done.

©ompass360° (augmented reality) 0.9.8 - memory consumption

Share on Twitter Share on Facebook

In the early days of the project it used about 56 MB. I didn't measured it exactly, just counted back from the current values. It used a 4048x2024 dimensioned bitmap (RGB with Alpha, so 32 bit) to render the compass, then one day it told me that iPhone is Out of memory.

I was shocked, and realized that the 4 channel of my image is really pretty useless, only one gray channel (can say luminance) is far enough. I wiped out all channels ended up with a grayscale PNG with no alpha.

So I'm playin' around now with instruments, and I can see that the process compass3D allocated 20 MB of real memory. I tried to detach different views to see the memory consumption of each element, so the app with the preferences view only eats 5 MB, with the display view added (the labels and the camera overlay) it needs 8 MB, and with the OpenGL compass it needs the 20 MB.

So the compass itself needs about 12 MB approximately (I counted the initial 56MB by this data). I decided to give PVR texture compression a go. If I use 4bit PVR, the 12 MB falls to 10.9 MB, in 2bit PVR mode it falls down to 6.3 MB (!) which is really cool, but the image quality is quiet JPEGgy at 2bit PVR.

So I can trade image quality to 5.7 MB of memory. Am I really want to do this? (No.)

The iPhone 3GS has 256 MB memory, and 16 GB of hard disk space. I can see some application running in the background that allocates 13 MB (Flight Control), 12.5 MB (Geared), and many system application that uses about 8 MB in the background. I think they all use much more when they're foreground, so I decided not to trade my image quality to 5 MB of memory.

That's all, memory optimization is done.

I belived that I can submit the app, then suddenly I recognized that the heading angles are still the "raw" heading values that CLLocationManager returns, but I need the "actual"/"3D" heading values that my 3D compass view shows. It must be implemented since the name promises a full 360 degrees compass.

Tha last piece of the whole puzzle. Let me get into it.

©ompass360° (augmented reality) 0.9.5 - something that I just cannot debug

Share on Twitter Share on Facebook

As you may noticed, the project is stuck. The problem is that I just cannot reveal the problematic part. Something is about storing the application run-time settings via NSUserDefaults, but it is works for an extent and suddenly after about 4-8 launch it never launches anymore (this is the same symptom that compactTangram© produces at the moment).

I tried many NSUserDefaults approach, but this happened all the time. After an hour of testing I came up with an interesting result. The application has three settings: a North source (true/magnetic) Boolean, a Notation (Sexagesimal/Decimal) Boolean, and the Field-of-view Float. I can launch the app several times with any configuration, but when I set the Notation to Sexagesimal (sexagesimalMode is YES) and North source to Magnetic (trueNorth is NO) then I can never launch the application anymore (the values can be set to these states "separately", but together).

The "deadly" preferences pattern.

I don't know what the hell the problem could be with these values, but maybe someday I'll find it out. Maybe some other methods causes the crash that uses the "freshly" loaded values.

This is soo annoying since the application is ready to submit to the App Store.

Update: I logged the loaded default in my loader method and noticed that it executes twice. I simply made a Boolean variable that prevents it from run more than once, and the app now works. Its weird but it works. Anyway, I don't like that I don't know why is it working.

Acrossair noticed the fullscreen camera preview "gap"

Share on Twitter Share on Facebook

I was happy to see that acrossair debugged that black bar at the bottom of their camera preview. Who knows? Maybe they're scanning the internet to see their products in the mirror of social media, and found the post that mentioned acrossair's camera preview bug.