Is there any way to maintain 2 different versions of the same app on the iPhone? One version is the actual production build and another version is the development build which I can use for experiments i.e. UI changes
Xcode 4 allows you to create targets for your applications. You might find those useful. I use them to maintain a free version and a paid version of my apps.
http://developer.apple.com/library/mac/#featuredarticles/XcodeConcepts/Concept-Targets.html
Each target should then have a different bundle ID as this is what the phone uses to distinguish different apps. If you need a specific ID, (i.e for push notifications, game center or iads), I'm not sure on a solution sorry
You can change the Bundle ID of the development version. You can install different versions of the same app if the bundle IDs are different.
Related
I want to have Meteor as a server and Ionic2 as a client. I currently have a headache with authentifiacation. It seems that there are two different approaches:
First is use of Meteor server and Meteor client with ionic-angular library. This approach described here
https://angular-meteor.com/tutorials/socially/angular2/ionic2
I guess the advantage of this method is use of Meteor native architecture, on the other hand I guess we're using Ionic2 just like a subframework and maybe loosing some stuff from native Ionic2.
The second is using separate Meteor server ('client' folder deleted completely) and native Ionic2. This approach described here
https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication
This option is vice versa: use of native Ionic2, but it has to use libraries like meteor-client-side, accounts-base-client-side, accounts-password-client-side etc, which I'm not sure are native for Meteor.
The first approach looks better, because there is a ready-to-use UI component for authentification. But I wonder what issues I would have, when I come to the step of completing my applications for different types of devices.
Thank you in advance for your help.
These approaches are essentially the same for the authentication itself.
What you are pointing out is more about what mobile platform to choose to develop and run mobile projects.
In the first case, you use Meteor's built-in Cordova platform to run the app and Meteor's compiler and bundler plugins (like TypeScript package or Meteor core packages for Babel and UglifyJS etc) to develop the app. In the second case, you develop and run the app solely on Ionic 2 CLI.
But from the app logic point of view these approaches are absolutely same: you import the same Ionic 2 components and use the same Meteor packages with the only difference in the second case is that these packages are now NPMs not Atmosphere ones (essentially though they contain the same scripts since these NPMs are built from Atmosphere packages).
The reason why What’sApp clone is built in that way that differs from the Socially’s one is simply described in the README of
the What’sApp repo (see https://github.com/Urigo/Ionic2CLI-Meteor-WhatsApp). If to repeat: since Ionic is a one of the best Web frameworks that specializes solely in building mobile apps, it’s reasonable to guess that it’ll be (and likely it is) much more powerful in building them than Meteor itself. From that point of view the second approach seems more future-proof, I would say. You could think even of building your project in some way that will allow you to substitute Meteor easily with some another framework if you decide to use it at some point in the future.
If you are though concerned about using those NPMs mentioned in the second case (e.g., if the process of building them doesn’t look transparent to you), you could try this project https://github.com/Urigo/meteor-client-bundler to bundle Atmosphere packages you need into separate scripts and use them after.
I have version 1 of my Windows Phone App (w8.0) in the store which has been running for a while now. The app uses a SQL Server compact database for local persistence on the device.
I'm now ready to release v2 of my app (w8.1), which has a number of database schema changes. The question is how I can formally setup a test environment for the test team where testers can:
1...Install v1 of the app from the store
2...Run it up and do some light activity
3...Then upgrade the app on the phone to v2
4...Continue testing using an upgraded version of the database
Up to now all v2 testing has been done using a shiney new install of the app.
I know i can do this using Visual Studio, but this defeats the objective of the test i.e. a live user upgrading via the store.
I've tried using the app deployment tool, but this deletes v1 of the app (including the database) when it deploys v2. I was surprised it did this - I thought it would recognise the install as an upgrade. I can verify this because it deletes the database. I am using the same names/keys in the manifest, including an incremented version number.
For now I have a new (hidden) TEST app in the store where i've submitted v1 of the app. Once the testers are ready, I submit v2 of the app to the store which the testers then upgrade. Problem here is that it takes upwards of 12 hours for the store to publish the upgraded version.
I am aware that you can install an app from the SD cards, which is pretty close. Has anyone else found a good elegant way to do this?
You could use Windows Phone Power Tools to achieve this.
Here's the link: https://wptools.codeplex.com
Just install the old xap, do some stuff and then update to the new xap using the "UPDATE" button. If you don't change the app ID, it will surely work.
Hope this helps! :)
I need to maintain in parallel two version of the same applications. One for app store and one standalone (not app store) version.
My initial plan was to use the master branch for developing all feature that are common for both version. For standalone version my plan was to create a new branch, and in that branch to add a features for standalone applications, and the same for app store version.
Actually I tried my plan, but I have a problem with cocoapods. I have multiple dependencies that are common, but for standalone application I need to use a Sparkle framework. Now every time I try to merge master to one of my branches I have a huge conflicts with cocoapods files. That are very difficult to solve.
I was thinking about removing pods for my source control but than, when I switch branches I will need to do "pod install" every time.
Is there a better way to do this?
Thanks.
I strongly recommend to use Targets.
Look Apple docs and here.
I'm prepping an application for submission to the Windows Store that utilises the Bing Maps API - as such, the app has to be compiled to target specific architectures. Whilst there is a guide to submission, it's not clear how to submit both Arm and x86 configurations of the same app. Is it even possible, or will there have to be in the store twice?
When you select the option to create your app package from the Visual Studio Store menu, you get a choice to select the package architecture. There are 4 options: Neutral, x86, x64, ARM.
If you select Neutral, then it builds a single package for "Any CPU" that you can upload to the Store. If you select x86, x64 and ARM, it will build a package for each of these configurations, and you will have to upload the corresponding packages for the architectures you wish to support.
Additionally, if you're building to submit to the Store, make sure to always select Release for each of the selected architectures.
There are cases where some references don't support building using a Neutral architecture. The Microsoft Visual C++ Runtime Package is an example.
Taken from here:
The process of engineering for ARM was different for each language (JavaScript, C++, and C#/VB), based on existing implementation details
of the various runtimes and compilers.
JavaScript uses a JIT compiler, so platform targeting is taken care of at runtime. Therefore Metro style apps using JavaScript are
platform neutral, and you can write once to run on x86/x64/ARM.
C# and Visual Basic are also abstracted from hardware differences. They compile to MSIL, which is platform neutral. Therefore, Metro
style apps using C# or Visual Basic can be compiled once to run on
x86/x64/ARM.
C++ is close to the metal, and compiled to the machine language for
the platform that you’re targeting. This offers developers full
control, but also requires that they specify the hardware where the
app will be supported.
The essence of it is that pure .net or pure html/js will run on any architecture without problems. If you want C++ then you will need to compile your app once for each supported architecture. My understanding is that you can create an app package which contains installers for multiple architectures in this case.
The post here has some good details on packaging your app for multiple architectures. Here are a few highlights:
7.In the Select the packages to create and the solution configuration mappings section, select the check box for each build configuration
for which you want to create a package.
The build configurations grid lists the possible platform
architectures of the package (that is, Neutral, ARM, x64, and x86). In
each row, a combo box displays the combination of the current Solution
Configuration and Architecture choices that are relevant for that
row’s architecture. The check box for the default platform is set to
the current, active project platform. The combo box for the Neutral
row show the Solution Configuration combinations that contain AnyCPU
as the project’s platform. If no Solution Configuration combination is
relevant, the entire row for that platform is unavailable for
selection. One package is produced for each configuration that you
specify.
8.For each build configuration that you specified, choose the Solution Configuration that you want to build.
When you package an app for the Store, you can specify Release or any
custom solution configuration that you’ve created.
A package will be created for each build configuration that you
specified.
From here we get this:
7.Click Packages to upload your app's packages.
And finally from the previous link:
Signing and publishing
After your app passes the certification testing, its packages are
digitally signed to protect them against tampering after they have
been released. When this phase begins, you cannot cancel your
submission.
Note It might take some time for your app's listing to appear in
search results. This is normal. Also, you can't change a release date
after you submit the app to the Windows Store, but you can cancel the
release, update the release date, and re-submit.
Overview: During the build process you specify all architectures you want your app to work for and it creates a package for each. During the submission process you select all the packages you built for that app. When submitting you app this way only one version will show up in the store.
If you build just a HTML5/javascript Windows Store app, it work on all version (ARM, x86 and x84)
If you create something web with bing api. No worry about what platform doesn't work.
Answer is here: http://developer.android.com/google/play/publishing/multiple-apks.html
TLDR:
Go to your Google Play app developer console
Choose your app
Select APK on the left
Turn on Advanced Mode
Upload your ARM apk
Upload your x86 apk
Google will figure out the rest
I have a really annoying problem. My app is published in the AppStore.
Everytime i run the app from Xcode, the iTunes binary just gets overwritten... and next time i need to test something with the production version of the app, i need to re-download it.
Is there any way to solve this?
Thanks in advance!
You need to change your bundle identifier. Here's how I set it up in my projects
Select your Project
Select your target
Navigate to the Info tab
Change the bundle identifier to a custom build setting e.g. I have it as ${BUNDLE_IDENTIFIER}
Now click on Project - (you may wish to keep at target level your choice)
Navigate to the Build Settings tab
Scroll all the way to the bottom to see User-Defined
Click Add Build Setting
(1) Select Add User-Defined Setting
(2) Add Key as the name you chose earlier
Set a different bundle identifier for each scheme
Bonus
You can use the same trick for icons so you can easily tell apart your builds on one device
Changing the bundle identifier, as Paul.s suggested, works — but it means your Release and Debug builds will diverge. Technically they will be different apps that use different containers. There can be good reasons to do this, but it has it's risks too: it's a bit more complicated, and you usually have to work a little harder to make sure you test that the development version properly handles data from the production version. You'll want to make sure any ad hoc builds you send to testers use the production bundle identifier.
Another way to approach the problem is to streamline installing the old version. If you Archive your production builds, then you can install them without downloading them again through the App Store. Just open-up a previously exported IPA and sync.