Hello, My App is almost ready to be deployed in Appstore. Therefore, I would have A question: which is the best approach to test new features of this app ? Any change I will do in Buzz will send the update to the LIVE app. I would be interested in your approach (I've read the tut written by GoNorthWest) tHANK YOU.

How complicated is your app? Is it feasible to have a duplicate app? How frequently will you update? How urgent are the updates? Fred

Hi Fred. How complicated is your app? --- > around 60 screens, external calls Is it feasible to have a duplicate app? ----> no How frequently will you update? ----> hard to tell you know. the updates will be provided for new features only or making the current features better. How urgent are the updates? -----> i dont foreseen any bug right now. The updates arent urgent

When you first deploy the app and immediately after an upgrade of an app you should have the app online especially if you don't use the Ad Hoc method for testing. How many of us wish we could correct a post immediately after it's published. Can you deal with a week or more of complaints, refunds, uninstalls and bad ratings because you couldn't immediately fix an oversight. Process should probably be something as follows: Step One: Build app Install on device Build ad hoc network Fix bugs, oversights Publish Online App Fix bugs, oversights Take app offline Step Two: (If feasible, use duplicate app to test add features) Add / Test new features Take app Online with updates Fix bugs, oversights Repeat Step Two as necessary Fred

Danny, I'll throw in my 2 cents. I've always suggested 'offline' in respects to it building it's screens from a buzztouch server (either this one or your own). I understand the sheer strength and flexibility of having an 'online' app, and being able to make changes on the fly, but I feel the stability of being offline is more important. Most of us witnessed the actions of the 'Anonymous' hacker and his widespread DoS attacks. It was reported that the overall traffic worldwide on the net was increased to the point of people and websites unrelated to his targets could feel the impact. And if you've been around here long enough, you've seen the effects of someone's success on David's servers. Now put yourself in the shoes of one of your potential users. Would you tolerate an app you've downloaded or purchased not loading, or taking long in between screen changes? That's not what they are used to. There are ways to compromise between online and offline. If you build an app that is offline (in respect to screen URLs reaching back to a BT server), you can always have some of your pages reach out to live content - whether its a HTML page that you can change on your own server (or dropbox, etc). Or if the content is fed by RSS, etc. I.E., you can have 'online' pages on an 'offline' app. But the bottom line question I always ask when this subject comes up (here or with clients) is this: Do you expect to have people actually download and use your app? Would you be happy if hundreds of thousands of people found and downloaded your app? If so, either build an offline app - or build the server farm to support it upfront.

I think it really depends on the type of app. I have three apps in the store right now, and two are online, while one is completely offline. The offline one is called 'AZ Fishing Spots,' and I envision it being used at various fishing locations around the state, most of which aren't going to have a network connection. So, it makes more sense to have the app offline, and provide as much data as I can via local files. That way everything will just be there for the user. Another app, 'OVFPS,' I created for our local girls fastpitch softball league, of which I help coach. Part of the content is offline (like docs on how to set up the fields, rules, etc), but some is online (like News, Tournament Info, etc). Overall the app is online, as it has both the Configuration URL and Report to URL set, but the content varies between offline and online. I choose this method so that I could push out updates to things like the News section (for cancelled games, etc), while also providing stable access to other information. The problem still remains on how to roll out new features. For me, I created a test app that I model and test new features for my online apps on. I make sure everything looks good, then duplicate that content in the real app, confident that it's been fully tested. I do it late at night so as to not affect any active users. That's just one approach on the whole problem. Looking forward to other comments! Mark

I think to properly understand the issue you need to separate the parts. An Offline app is not about an app that works in the wifi / 3G / 4G locations. Apps for those locations can be online or offline. Functionality depends on what's embedded and how. The orginal post is about testing new features, online vs. offline. A totally separate question is should the app be and online or offline app. It's probably appropriate to take an app online or offline for different stages of the app. It's my opinion that initially publishing an app offline is extremely risky and prone to failure. New developers because lack of experience, and experienced developers due to lack of attention. Once the app is functioning and stablised then you should consider online vs. offline in terms of Use of the app Updating the app Life stage of the app. Whether you ultimately publish an app online or offline Later take it online or offline Leave it on or offline, Will depend on: the nature of the app Design of the app Skill of developer Ease of updating (think iOS needs approval, android probably will not need third party approval.) Business model (online purchasing, android licensing, . . .) Fred

Thank you all for answers. Indeed. The scenario: my app cannot be duplicated and it needs to be online. Also, I am sure I need to release some updates as soon as I will have more feedback. Therefore, I think of: 1. I will link the app to a config.txt saved on clouds on a tier server (eg: Amazon s3) 2. i will test my local app till the new version is ready. 3. when it is ok, I will update the config.txt on cloud. Of course, i have to change the dataURL and reportToCloudURL to NULL values. dataURL:, reportToCloudURL:, I will fill in the full path when the new version is ready. I dont know if this model works as I am really NEW in the Buzz world but I will give it a try.

One thing to caution you about the above (from personal experience) is you have to really think out the potential of having multiple users in various states of upgrade. Example. At any given time, you could have a user with your version 1.0; a user with version 1.1 (downloaded direct from app store); and a user using version 1.1 (upgraded from 1.0). (The latter two not necessarily having identical versions of your intended app, believe it or not). Depending on the order that you change your dataURL's, you can get into a nasty update circle. Its hard to explain, but the end result is you having to hurry an update to the store (v1.1.1) to correct the circle. Totally avoidable if all thought out ahead of time. Thus the word of caution. @Fred - I see your points. And I realize that your experience is much more on the Android side. I would never dream of submitting an app to Apple that I thought for one minute had the potential of an error. I realize that even with stringent testing, its possible for even a seasoned developer to miss something before release, but I'd rather the burden of trouble with any of my apps be on my actions, rather than something I cannot control. Overall, there should be plenty of insight in this thread for anyone else that stumbles upon it.

Yes I agree I would never dream of . . . But what brought down the space shuttle was complexities. That's why they're called latent defects. Not always possible to see all the permutations. It's how to handled them. Fred