I developed an internal windows phone 8 app and published to the market. The app works when debugging but when i published the app to the market and downloaded the app and opened it, only says: Loading... and nothing more. It wont open.
Has someone face this problem before? What can i do to fix it?
I have tested the app in dev environment in a virtual device and the phone itself and works. The app does not crash or report me any errors so i can get any info about what is going on. Only happends when it is downloaded from store.
Update:
Physical Device info:
Nokia Lumia 365 Windows Phone 8.1
Solution:
Basically what fixed the problem was change from debug to release mode and the plamaform to ARM.
I've ran into this before. The first thing I'd do is see if you can get any crash info from the developer dashboard.
Secondly, are you using any third party libraries such as SQLite? Sometimes they need to be built specifically for an environment, so when publishing make sure you're building for ARM and not x86 or Any CPU. This was the issue for me. I needed to build specifically for ARM and go through the process of getting SQLite to work properly.
See this link for common issues:
https://support.microsoft.com/en-us/kb/2859130
The following issues are known to cause the app to crash only after the app is installed from the Windows Phone Store and during Certification Testing. When side-loaded, the application runs fine.
- Calling ScheduledActionService.LaunchForTest in a Windows Store installed app. Make sure all debug APIs such as ScheduledActionService.LaunchForTest are not included in your release build. The app will crash otherwise.
- Writing to the InstalledLocation folder in a Windows Store installed app. Do not write to the InstalledLocation folder in your production application release submitted for certification. This will cause an app crash. The folder is readable and writable before it is published, but in the published app, the folder is read-only. You can however read and write to the Local Folder. For more information, refer to Data for Windows Phone.
- Coding a dependency on a hard coded product id value. Before Marketplace deploys the app, its ingestion process changes the ProductID in the WMAppManifest.xml. Perhaps your app has some dependency on the ProductID that existed beforehand. An example is if your app has a hard copy of the old ProductID in a string constant. Your app may need to explicitly open WMAppManifest.xml and then inspect the ProductID in order to get the correct value.
- (Windows Phone 7 only) In the Dashboard, inspect the list of Capabilities for your published app, and ensure that Marketplace didn’t remove any. This problem can occur owing to the various ways Marketplace audits the app in order to identify what capabilities are needed. The solution depends on which capability is missing. As a Windows Phone 7 example, for MediaElement to be detected, its name needs to exist in the xaml itself (x:name). Find more information about Capabilities here.
- Submitting a XAP file for x86 instead of ARM. Ensure that you built your solution targeting the Device not the Emulator. The Emulator compiles to the X86 platform while the device compiles to ARM. In this case, the app won’t be able to be tested.
- App won’t load on low memory devices (512 MB – Windows Phone 8). See if the failure is specific to a particular phone model or manufacturer. For example, determine if the problem is related to the amount of memory available in the phone.
- If your application does fail certification, make sure you refer to the “Windows Phone Tested” section of the failure report for a list of devices on which their application was tested so you can attempt to reproduce the failure on the same devices if possible.
- Developers should pay attention to the failure reason comments in the Certification Testing report to see if the issue was encountered on Windows Phone 7, Windows Phone 8 or both platforms and make sure you are attempting repro on the correct device/OS. These scenarios are known to cause Dev Center submission and/or run-time errors:
- Not running the Store Test Kit prior to submitting your app to Dev Center. In Visual Studio, under the PROJECT menu, choose Open Store Test Kit. Execute the automated and manual tests. Make any necessary corrections. More information is available here.
- Submitting to Dev Center a debug, instead of a release build of your app. Make sure that when you built your solution, you did so in Release mode, i.e. not Debug mode. In Visual Studio, check this using BUILD->Configuration Manager… If you uploaded a Debug build you will get static validation errors during submission, for example if the app includes native code. Also a debug build will generally result in an app that runs slower to the end user, because of extra debug checks and diagnostics.
- Ensure that the XAP file contains all the DLLs needed. For example if using the Windows Phone Toolkit or other third party libraries, make sure the references to those DLLs indicate CopyLocal=true. Your XAP file can be found in the Bin/Release folder of your project. Inspect its contents by renaming a copy from .XAP to .ZIP. Then double click on the newly named file to inspect its contents. You also can inspect it by using a third party tool such as WinZip.
- Also while inspecting the XAP, make sure all the DLLs that are present are known, expected DLLs, and those DLLs have been compiled specifically for use with your particular version of Windows Phone app and build environment. You might need to launch a clean build to ensure there are no unnecessary DLLs.