The following code is in BT_application.m //set "currentMode" (live or design) in app's delegate... if([thisApp objectForKey:@"currentMode"]){ if([[thisApp objectForKey:@"currentMode"] length] > 0){ [appDelegate setCurrentMode:[thisApp objectForKey:@"currentMode"]]; }else{ [appDelegate setCurrentMode:@"design"]; } } Notice that it defaults the value to "design" if something goes wrong. Something is going wrong. The value is getting stuck on Design instead of Live. It seems there are only a couple possibilities, and only one of them looks probable. Either 1. the "length > 0" test is failing (improbable), or 2. the value of -> thisApp objectForKey:@"currentMode" -> is not properly obtaining the right data Thoughts? How could it obtain a value, thus allowing the first "if" condition to be met, yet have a length of 0? Or how could it have a length greater than 0 yet still wind up getting defaulted back to Design mode?

"In my humble opinion" things still need some solidifying on the server side. If we look at how things look 'from the bigger picture', you can see where the issue are coming from. 1) Just before you 'button up' your app for distribution, you should always take a fresh copy of your BT_config.txt from your app control panel, and overwrite the existing project BT_config.txt. Hopefully you'll use a 'live' config. You already know in the json, there is a key/value pair for this at the 'app' level. 2) Just as you say, the live/design mode is initially discovered in the BT_application.m file and this sets a 'global' property that exists throughout your app (although isn't really used 'that' much). 3) It is still actively being used in your 'reportToCloud' and 'registerForNotification' URLs sent back to the server. Once it gets there, it disappears into technology for which 'we' have no documentation. I have 'jury rigged' a solution that worked somewhat... but there were other issues that kept me from implementing the fix. Those issues were: 1) Serious difference between 'design' and 'live' config. Most notably, I found in my 'Live' config, an app lost it's context menu configuration information. That was a biggie; had to have that. 2) There is an HTML tag called a 'curren', for a symbol that looks like this: http://character-code.com/currency-html-codes.php the problem sometimes happens when the BTCore adds to the Report to Cloud or Notification URL strings... it adds : &currentMode="whatever" and what can happen (and has happened) is that the HTML processor will interpret "&curren" and replace it with that odd currency symbol. I've gone through my self hosted install, and changed 'currentMode' to 'curMode' and that worked out great... until I needed to download my app. At that point, my modifications didn't sit well with existing infrastructure, and I was unable to download a copy of my app until I reversed all my changes. So for the moment, I'm getting by like everyone else... design mode, precariously. Cheers! -- Smug

Thanks, Smug. Helpful info, as always. Before buttoning up my app, I did download the latest "Live" version of the config file and use it in the app, and I verified that the "live" version of BT_config was actually in the final deliverable, because I opened up the ipa file and looked inside. Yet when BT_application.m runs, it somehow was defaulting to "Design" mode, despite the fact that BT_config was definitely set to "Live." Then there are the infrastructure issues you mentioned. I had run a side by side comparison (using FileMerge) of the Live and Design versions of BT_config, and I had noticed that "BT_menus" was missing from Live while it was present in Design. However, since my app was not using any, it did not affect me, so I must have mentally glossed over it until now.

I've also noticed that for my live app in the App Store, which is wrongfully getting registered for Push Notifications in "Design" mode, when I try to send a Push message, it does not show up, regardless of whether I send it to Design or Live devices. On Live, it just says none are registered. On Design, it says message sent, but the message never shows. But the same app, before publishing to the App Store, when sideloaded in Design mode, was getting Push Notifications just fine.

I really need Push Notification to work. I am grasping at straws on it.

I suspect you can probably drive it to deliver 'live' configurations, but you'll need to edit some of the php files on your self hosted server. I can't remember which ones they are right now, but I'll snoop around later today and get back to you on that. I tried to add '&currentMode=live' to a URL string, and most of the time it works, but sometimes it seems to trip with the HTML trying to 'interpret' the '&curren'. I stuck it at the end of the DataURL. Cheers! -- Smug

Well, I have progress to report. I discovered that my Apple Provisioning Profile for Production Mode had somehow gone to an invalid state at the Apple Developer site. I edited it and got it "green" again. Then... after having edited the above code in BT_application.m so the "default" is now "Live"... my BT Push (on self hosted) is working! I'm encouraged! Below is how I edited the above code: OLD: //set "currentMode" (live or design) in app's delegate... if([thisApp objectForKey:@"currentMode"]){ if([[thisApp objectForKey:@"currentMode"] length] > 0){ [appDelegate setCurrentMode:[thisApp objectForKey:@"currentMode"]]; }else{ [appDelegate setCurrentMode:@"design"]; } } NEW: //set "currentMode" (live or design) in app's delegate... [appDelegate setCurrentMode:@"Live"]; /* if([thisApp objectForKey:@"currentMode"]){ if([[thisApp objectForKey:@"currentMode"] length] > 0){ [appDelegate setCurrentMode:[thisApp objectForKey:@"currentMode"]]; }else{ [appDelegate setCurrentMode:@"Live"]; } } */

Do me a favor, if you would. Add some kind of a 'context menu' in your app, and check to see if it shows up in both design and live configurations? (it should show up 'after' BT_Tabs and 'before' BT_screens, it's called 'BT_menus') On mine, it only shows up in 'design', and I'd like to see if it's just me, or is it prevalent on self hosted. Cheers! -- Smug

Will do. I had already noticed that an empty "context menu" section was in my Design config file but was conspicuously absent from my Live config file. I will add something and double check.

That's the part I'm worried about. I can hodge podge my system into determining 'live' and 'design' (although a bit of it is 'hard wired'), but that little detail keeps me from doing it; I use context menus for things like 'about', and 'contact ...' etcetera... small detail but very important, lol! Cheers! -- Smug

Smug: I did a test, like you asked. I can confirm that the issue of "context menu" options not showing up in the "Live" config data is happening for me on my Self Hosted control panel just as you have experienced. -Doug

Bummers. I was afraid of that. Sort of a deal breaker for me, I use a lot of context menus for miscellaneous things, like email author, device info, gps on/off, etc... Gotta have it. Oh well. We'll wait. Cheers! -- Smug

Since presumably a PHP script is writing it for design, but not for live, and since I am pretty good with PHP script, I may be able to get a handle on a fix. May take a crack at it.