Decoding graph for large vocabulary tasks (more than ~10k words) need to be built ahead of time, and bundled with the app or downloaded after the app has been installed. It is currently not feasible to create large decoding graphs on the device due to memory and CPU constraints. Contact us for more details and help with creating these decoding graphs.

In the future we are planning to provide tools that will allow you to create custom decoding graphs, as well as a set of decoding graphs (generic and domain specific) for large vocabulary tasks. We can also help create language models and decoding graphs for domain-specific tasks (e.g. medical, construction, industrial, etc.) using existing data from your enterprise systems.

The SDK provides startListening method which will usually be user initiated; for example, user will tap a button on the screen to initiate speech recognition session. You can call stopListening to explicitly stop listening from the app, but we recommend you rely on Voice Activity Detection and let the SDK stop listening automatically when the user stops speaking. See Getting Started for more details. You can also build decoding graph with trigger phrase support -- in this case, call to start listening method initiates continuos listening until trigger phrase is said; after that recognizer listens in the standard mode and stops when one of the VAD threshold is reached. Trigger phrase support is not meant to be used for long (more than couple of hours) sessions.
ASR Bundle on-disk size will typically be between 30MB and 60MB, depending on which acoustic model is used. When compressed, the corresponding size would be about 20MB - 45MB, which is how the app size would be affected when downloading from the App Store.

If this is still of concern, instead of including the ASR Bundle in the app, you can download it when the app is started for the first time.
We currently provide ASR Bundles for English (US and UK). We can provide ASR Bundles for majority of frequently spoken languages within 6-8 weeks.
Children's voices are different from adult voices, so it's recommended that acoustic models trained on children speech data are used; we are in the process of creating such acoustic models. Note that in case of small vocabulary tasks, even adult acoustic models can work well for children. A couple of our customers are using acoustic models trained on adult speech in children apps.
Make sure that decoding graph is (re)created after you updated the list of phrases. SDK provides ways to check if the decoding graph exists in the file system, so that you don't have to create it every time the app is started. When you change the input to the decoding graph creation methods (by augmenting or modifying list of phrases, for example) -- typically during the development -- you will need to make sure that the decoding graph is created using new input data, i.e. you are not skipping the call to create decoding graph, because it has been created in the past.
For the most part no, you cannot (or should not); our SDK assumes it has control of the audio stack on most platforms. This way we can guarantee that audio is captured in a way KeenASR SDK expects it. We typically initiate audio stack for the most general use and provide callbacks that allow you to setup other SDKs/audio modules in a way that will not interfere with our SDK. For more details see Audio Handling section of Getting Started document.

If you have a specific use case that doesn't match current SDK capabilities, drop us a line.
We recommend you log complete recognition result in partial and final callbacks. It is also useful to display this information on the screen during debugging and early user testing. Even if you don't plan to show this information in the final product, this will help you catch errors early on.

Review console/logcat outputs and review log messages with warning or error levels.

It's also useful to have visual and audio indication on when the app is listening; this is a good general practice, not just during debugging.

If you are doing user testing, you can connect your app to Dashboard and automatically send audio data and recognition results to the cloud for further analysis.

For assessing speech recognition performance, the best approach is to collect a small amount of test data. You can run the SDK against the files to assess, in a controlled manner, how well the recognition works.
This depends on several factors: 1) how big is your language model, 2) how much CPU and RAM do you have? 3) how often do you need to create decoding graphs? In general, if you are dealing with more than 10,000 words and/or if the content you are using to create decoding graph is large (> 25,000 phrases/sentences) you will probably want to create decoding graphs ahead of time in your development box (you will need to work with us).

Note that decoding graphs created on the device are not using rescoring approach in decoding. Also note that this answer relates to the process of creation of decoding graphs, which is typically done once.

Consider this as a baseline; ultimately, you will want to test this on devices that will be used in production setting.
Memory footprint will be driven by the size of the deep neural network acoustic model, and the size of the decoding graph (primarily langauge model that was used to build the decoding graph).

CPU utilization will also depend on the size of the model (there is a fixed CPU processing related to the size of the acoustic model; for each frame of audio, audio features are pushed through the deep neural network). The other factor for CPU utilization is graph search, which will depend on the size of the graph (size of the language model) as well as various configuration parameters.

For medium vocabulary task (e.g. searching movie library with ~7000 titles), memory footprint with the in-house ASR Bundle will be around 100MB, and CPU utilization will be around 40% of a single core on iPhone 6s.

We are working on a number of optimizations for mobile devices that will significantly reduce memory footprint and CPU utilization.
Yes, as of version 1.5 you can disable notification handling by SDK by setting KIOSRecognizer's handleNotifications property to NO. You will still need to make sure audio interrupts are properly handled and audio stack is deactivated and activated as necessary (e.g. when a phone call comes through), via activateAudioStack and deactivateAudioStack KIOSRecognizer methods.
For mobile apps, license is typically structured as a yearly recurring fee per product; depending on the type of your product/app this structure can be different (revenue share, per device/install fee, one time perpetual fee).

The price and the structure will depend on a number of factors; we don't have a standard price sheet for SDK licensing. To start the conversation, let us know what you are building and how you plan to use our SDK.

License includes iOS and Android SDKs, access to in-house trained ASR Bundles (including support for additional languages, as we expand language coverage), access to new SDK releases, and the use of Dashboard service during app development phase.
We are not providing software development services, so most likely the answer is no.

Via professional services agreement we can help with proof-of-concepts (these will typically be rudimentary apps with focus on voice user interface), evaluations on a specific domain/task, integration of SDK in your app, training of custom acoustic and language models, and porting to custom hardware platforms.
Please check this page for potential problems with line endings in text files that can happen with Github on Windows.
Please make sure you are building an app for the real device since KeenASR SDK will not run on simulator.

Another reason may be that on iOS you cloned the PoC project from Github without having git-lfs installed on your development box. Due to the large size of the library, some of the files in the iOS KeenASR framework are managed via git-lfs. If git-lfs is not installed, when you clone the library you will end up with a git-lfs reference file (a small text file) instead of a binary file. You can check the size of the library file (KeenASR.framework/Versions/Current/KeenASR); if properly checked out it will be 160MB or so, if not it will be very small (few thousand bytes).

Library in the iOS PoC app will also not be properly checked out if you just download the project zip file from Github.