When using the simulator in the Actions Console, I get the response:
"Since your voice wasn’t recognized, I can’t do that right now. Check the Voice Match settings in the Google Home app."
The account under which I am developing has no devices registered, intentionally. This account is used specifically and only for development.
Why does the simulator respond like this, and how can I fix it? The account has no "Google Home app".
I have another (personal) account which I've used to develop the Action initially. The simulator works fine there. Now I'm trying to move the development to an "official" corporate account, and the simulator fails completely.
I can confirm I'm getting exactly the same occurrence here.
Doesn't matter what device type is selected as being used.
Similarly was working fine a couple of days ago.
Looks like Google has broken something with account linking and the Actions on Google Simulator.
I did however read somewhere that best practice you should be delivering some functionality that does not require account linking. That way you will still get explore ratings from users who visit your assistant but refuse to sign in.
However that doesn't fix the core issue of testing functionality that requires sign-in using Actions console simulator.
We have an App which is intended to run on a LAN reading a company's own feed and producing local reports with it.
In order to do this I need to enable read_stream but I note that this is not possible without submitting an App for Review.
However in order to do this I need to choose a platform. I am only able to choose between ios/andrioid/Windows App/App on Facebook/Website/Page Tab/XBox/Playstation
A Windows Server is none of these. I looked at Windows App, but this is asking for a Windows Store ID - we do not particularly want to put this in the Windows Store. We just need to turn on read_stream.
Also, I see that the Review Submission requires a minimum of 4 screen shots. This seems a bizarre thing to have to provide for a Windows Service.
Any ideas how I can navigate all this red tape ?
My client needs to find a way to automatically push app updates to a number of iphone 3gs devices remotely. These devices will be in guided access mode so the users will only be able to access the app in question.
I believe we have two option for distribution:
B2B custom app via the Volume Purchase Program
In-house app released with the Apple Enterprise Program
Having researched our options I can see that over the air app updates can be achieved by either:
Building an in-app update functionality to check for new updates (Enterprise only I am guessing?) and automatically update and restart the app
Using an MDM such as http://www.air-watch.com/ (as I understand Apple Configurator must have devices plugged in via USB to work?)
I am wondering if anyone can tell me whether either of those options are possible with the devices being in guided access mode?
Or are there any other solutions, which I have missed, that can automatically manage the app remotely while the device is in guided access mode?
You can solve this with an Enterprise distributed app.
App only. Update check for an OTA-Update from your app when the app is coming to the foreground (or some other metric at your clients leisure, like added time delay, etc). Basically self explanatory; you implement a call to your clients/your API to check the version and inform the user of a new one. The update can either be optional or mandatory (preferably announced by the API and changed when needed); present the user with an alert about it. The user acts upon it and you OTA install via an ITMS link provided by your API call. And that's it.
MDM. Tbh, I'm a bit on shaky ground here. Theoretically this is all possible via MDM too, however I am not sure if it is the (varying) MDM solutions or some misconfigurations, but clients usually seem to lose control after some time.
Both. Yes, you can perfectly well live with both. MDM while everything is fine, and as a backup a well structured App+API mechanism to push the OTA updates out. This is especially useful if you have customers where some departments are under MDM and others are not. So, some may get it via MDM (and if all else fails via the App itself), the rest will get it via the App.
The tradeoffs are a matter of personal preference, if there is a fully working MDM solution in place the update will be pushed out and the user however 'malicious' can do nothing against it. But the same is true for the 'App only' solution, as you have the option to not let him use the app if he does not update (either by not providing a cancel button or, as you are in an enterprise environment and there it is allowed doing an exit(0)).
From experience I prefer any solution that has the 'App only' option as it is the last fallback if anything on client side fails. Whatever may be added on top is just sugar to the cake.
While not strictly relevant, the 'App only' solution always goes well with Push Notifications when an update came out.
I'm using IOS Simulator v6.0.
Device is iPhone (all iPhone devices behave the same with regards to my problem)
IOS version is 6.1
I'm attempting to download a p12 via a web app using the built-in safari browser.
When the download completes the user is automatically taken to the settings app (which I understand is necessary to complete installation of the p12) - but there is no option to complete the installation. Ive read that a Passcode Lock is required for enabling certificate imports. However, I can't find out how to enable a passcode lock within the iPhone IOS simulator.
The doc I've read says the option should be within: Settings -> General -> Passcode Lock
Except its not. Is this a simulator specific restriction? Can I overcome it?
Neil,
Yes, as you've pointed out, the iOS Simulator is not a 100% accurate replication of the operating environment found in an actual iOS Device -- certain classes of interactions that are dependent on specialized hardware (cameras, gyroscopes, magnetometers, hardware-based encryption technologies, etc.) are naturally unsupportable in a simulated environment. Other classes of interactions that would seemingly be 'software-only' kinds of interactions are also prohibited on Simulator (Push Notifications, iCloud, etc.) -- these are attributable to a couple of things:
Unlike physical devices, you do not provision the iOS Simulator. Since Provisioning Profiles include entitlements for these Apple services, there is no (current) way for Simulator to understand how to connect to your specific app's slice of these services.
Simulator does not have a unique hardware identifier, so connections from your Simulator would be indistinguishable from connections on any other Developer's Simulator.
And finally there are the class of interactions that don't fit either of the exclusions from above that can only be attributable to design decisions made by Apple. Passcode lock, for example, can simply be enabled by security-conscious iOS device users...or it can be enforced by IT departments by way of Mobile Device Configuration policies (via ActiveSync, MDM servers, etc.) Adding only the generic, non-IT-mandated version of Passcode Lock would cause intra-Simulator feature parity as only the most Generic Passcode lock behaviors would be supported, leaving MDM users out in the cold. To avoid this, Apple would then have to endow Simulator with the knowledge to support .mobileconfiguration profiles, connect and periodically check with MDM servers (thus requiring unique hardware identifiers), and ultimately include the Mail.app in Simulator to allow for Exchange connections to be setup to enforce ActiveSync managed configurations.
As you can see, the relatively simple feature quickly spiders out to a host of other iOS elements that would also need to be simulated. Taking this to the most unlikely, extreme edge case, Simulator would become a full-fledged software-only iPhone where you receive calls and texts, check email, etc. directly from the iPhone shaped interface on OS X...not an experience Apple would like for users to have even though those users are their 3rd-party developers.
Though there are some interactions we can easily deduce the rationale for their omission from the simulator, only Apple really knows why they elected to exclude other interactions from Simulator.
So, back to your questions:
Is this a simulator specific restriction?
Yes, this is currently not supported in iOS Simulator as of Xcode 4.6.2.
Can I overcome it?
To the best of my knowledge, no.
I do, however, think that your lurking question about installing a Certificate in Simulator is something that you can do something about -- In fact, I installed a self-signed certificate authority into my Simulator to do some security testing about 2 months ago based in large part to some of the work presented by the Developers of the Charles web proxy.
If you download their shell scripts you can see how they injected self-signed certificates into the Simulator keystore -- assuming your ultimate goal is to get a certificate installed, you may be able to apply a similar process to your own certificate.
Do make sure to backup the default keystore; It would be really easy to accidentally break the binary data in that file and render your Simulator useless for all SSL connections.
As is likely tacitly understood, this is not a supported operation in iOS Simulator -- tweak Simulator at your own risk.
Good luck, and if all else fails, push your app to device where you can definitely get a certificate installed.
A client has asked us to develop a proprietary in-house app for managing their back-end systems. However, we are a small development company and I'm certain that their company does not have >500 employees.
Are there any alternative, yet similar, solutions to distributing this app to their company without going through the iPhone enterprise program?
(just to clarify: obviously, we would like to go through the official enterprise program but seeing how the company doesn't have >500 employees, this isn't possible).
UPDATE (27/09): It appears Apple have removed the 500 employee limit for the enterprise distribution See here. So this will probably be our route now (which is helpful because the app is approaching completion). I'll update this as we go through the process if anyone would like me to, so that others may get an idea of what the actual process is like.
You can submit the app as a completely free app on the AppStore but require that the user log in and authenticate to use it. That way anyone can download it but you control who can actually use it. Apple does all the distribution for you for and you don't have to worry about Ad-Hoc deployments or IT departments.
You then build a really simple configuration management system on a web host (or platform like Google AppEngine) that manages the authentication of apps.
When a user launches the free app they are asked for a username/password/whatever. That information is sent to the web-based configuration management system and confirmed. If the app receives an acceptable confirmation from the configuration management system it unlocks itself for use by that user.
The app can either re-authenticate every time it launches (useful if you want lots of control) or it can store a key file locally indicating that it has been authenticated. If it sees the local key file when the app launches it considers itself authenticated and never checks again.
Whether you use one user account per person or one for the whole company is up to you.
This style of distribution is very useful if you want to have control of who can use the app but want the ease of deployment that the AppStore provides.
Apple has accepted many apps onto the AppStore that use this method of authenticating against a remote server (Skype is a perfect example).
If you keep track of device UDID on the configuration server you can also pre-load it to allow a certain set of devices to work.
Further, nothing I have described is iPhone specific so you can use the same configuration management system and concepts on other platforms like Android (or even desktops) if you ever port the app or build other apps needing this in the future.
Also, since the action of authenticating devices is not processor or data intensive you will likely never incur a cost if you build this on Google AppEngine as you will never go over the free quotas and you will gain the stability and scalability of Google's backend architecture.
As this particular deployment is for managing an in-house back-end system deploying it through the AppStore can seem insecure because there is proprietary information embedded in the app, in particular the information that allows it to connect to and authenticate against the back-end systems.
The solution to that is to not include this information within the app and simply have that information be part of the response that the app receives from the configuration management server. Basically the app contains the logic necessary to perform its function but without the connection information it has no ability to manage any back-end system.
If you make the app authenticate every time it launches you can change the connection information on the configuration server and the app will update to the new information without any new deployment being necessary. The user just needs to restart the app. This gives your client the flexibility to change their internal network configuration without invalidating your application code. You could also make this information manually configurable within the application but then you incur an IT cost when setting up the application on each device and if you already are going to set up a configuration management system you might as well use it.
To further secure the above solution you may want to have the configuration management system be in-house and behind the company's firewall so that regardless of who gets a hold of the app they cannot connect to the config system unless they are within the company's network.
I was researching this yesterday and today, and it appears that Apple has just (within the past week) removed the >500 employee requirement for enterprise development. However, I believe you will need to develop/deploy for a particular client using a development toolkit registered by the client.
So if you do work for client A and client B, both client A and B will need to sign up with Apple as business developers, at which point you can develop apps for them (as a contractor) and use their tools to build and deploy within their enterprises. I would think it would be a good idea for your company to also be registered as a business developer.
Apple does still require you to have a Dun & Bradstreet DUNS number to sign up as a Business Developer.
About the only real choices you have are...
Up to 100 devices as ad-hoc distribution.
Enterprize distribution (requires > 500 employees)
Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
Jail-broken.
Jail-broken may sound scary, but it's actually pretty advanced, now-a-days, and can be managed quite easily. Still, it voids your warrantee (unless you're willing to restore-to-factory and be not-honest about it ;)
Still, technically, it's an available option and can be made to work, if you're willing to plan it out.
Let us know what you decide, and the pros & cons of that method.
Another obvious although not neccesarily pleasant is to submit your app to the app store as an app but can only be accessed with a client password. Assuming you can get past the aapp store process this might work for you.
Olie said:
About the only real choices you have are...
Up to 100 devices as ad-hoc distribution.
Enterprize distribution (requires > 500 employees)
Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
Jail-broken.
But to be clear (correct me if I'm wrong):
if you use the "Ad-hoc" distribution method, your costumers will see the app vanish after exactly 3 months.
only up to 100 devices can be used for testing (i.e. used in "developer mode") and moreover, the app will vanish after 3 months.
So, Apple doesn't give us any choice, are you really big (>500 employes)?? ok so you can do what you want etc otherwise... "byebye"
Moreover, forget about what "Bryce" said before, an app like the one he described would be rejected with the "limeted audience" motivation.
iOS is not for enterprise app....if you don't want to rely on some clever hackers (i.e. jailbreak)
Ad-hoc distribution is limited to 100 devices per app, that's true, but you can add the project n times to the apple developer center, so you can deploy it to n * 100 devices
How does apple ensure that your enterprise has greater than 500 people? I'd give it a go through the enterprise program anyway...
I would not jailbreak, I would not do ad-hoc because it is limited to 100, and I wouldn't make everyone put their phones in developer mode.
For future maintainability, enterprise mode is the way to go, so see if you can navigate your way through the process without mentioning that you might not be quite 500 users.
Also, I saw your comment about developing using MonoTouch. I would talk to Apple about this before you do anything else, because given their recent policy changes I am pretty sure this will get your app denied from the App Store and the Enterprise program.
Edit: I checked the Mono web page. It seems like Apple may still be letting mono apps in, and the Mono creators insist that it is kosher, but you might be running the risk of having your future app pulled from phones at any time.
A better edit: Straight from the mono website: Enterprise MonoTouch
It is important to point out that the new iPhone Developer Agreement terms are for AppStore deployment and not the Enterprise program that allows deployment of in-house application to users in the enterprise (using the Enterprise Deployment program).
So you might be good there as long as you can get into the enterprise program.
You can completely bypass the App-Store or Enterprise Developer Program approval process, if you develop your app as pure HTML5 solution.
This technology is called webapps. And they can be pretty advanced in functionality. You automatically have cross platform readiness and very easy deployment options (as webclip this can be distributed via .mobileconfig configuration files)
See http://www.apple.com/webapps/whatarewebapps.html
There is another solution: an own app store:
http://rhomobile.com/products/rhogallery/
unfortunately only in combination with RhoHub.
Or:
http://www.appcentral.com/
More info:
http://www.apple.com/iphone/business/integration/mdm/
http://www.cio.com/article/638175/Emerging_Tech_Alternatives_to_Apple_App_Store_For_Enterprises?page=2&taxonomyId=3002
In theory the proposed solution of publishing a free app meant for one company is not valid, since published apps in the app store should not be intended for a "limited audience" (whatever that means), according to:
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
Has anyone tried this with success? Any other ideas?