I am updating my build with a new UI and I changed the app icons. However when testing and running the new .dmg installs, the notifications keep displaying the old app icon.
Is there a way to clear the cache?
I think you can solve this by incrementing the Build number in the General section for the build Target. It worked for me :)
OS X apps typically contain multiple app icons which are used in different contexts (one for the App Store listing, one for Spotlight search, etc.)... have you done a search in the build directory to ensure that you don't have any only icons lingering in there?
I've had this issue before when I quickly removed the previous icons and added the updated ones but forgot to add all the sizes (thus it used the previous one for specific cases like notifications either because it was cached or still in the build folder);
What fixed this for me on 10.14 was to delete DerivedData:
rm -rf ~/Library/Developer/Xcode/DerivedData
Related
I am in need of advice of how to deal with something:
I have an app that will soon be published to App Store and Google Play, I would like to find a way to have a clone of this app with less features, this clone is meant to give a taste of the app for users and also for the salesman of the company to demonstrate it, also I would like to keep both apps installed in the same device, so in the case of the salesman, they could demonstrate with this "demo app" and also use the real app for their own purposes.
I know that I could just have a beta user group on TestFlight and Google Play but that would need me to register those users or give them a link to register as beta and would not be possible to have both apps installed.
I want to make this "demonstration app" to be downloadable from the stores, it would have different API calls from the real app, different icon, etc...
but I would like to avoid having to maintain and copying every change from the "production" app to the "demo" app.
The option I thought: create a branch and rename the app to the new signature, name, icons and so I will just have to always pull the diff from the origin/master branch and publish it on the stores, but it didn't worked, since xcode breaks the app and give me random errors when I do it.
I would appreciate to receive ideas and workarounds for this.
I can currently have four different versions of an app I developed installed. The solution for this really depends on your setup, but here is currently how I do it1. It is not the only way but it works for me and I find the issues that this setup causes so small that it doesn't really bother me.
iOS
The simplest solution for iOS is to have different Bundle Identifiers. This requires you to have different provisioning profiles. One provisioning profile for each development environment (if you want to put them on device for testing away from the development machine they need to be distribution profiles) and one profile for submission to the App Store.
Xcode has the ability to manage different environments with different provisioning profiles, however this caused me major issues when using CocoaPods and I ended up having to stop Xcode from managing it.
What I do now is I add a script to my workflow2 that forces the correct Bundle Identifier for the environment. If I want to build locally, I just manually change the Bundle Identifier and the provisioning profile (it only takes a second)
Android
For Android I use the built in flavors to manage the different environments. It is really easy to set up. in my app/build.gradle I added the following:
flavorDimensions "version"
productFlavors {
dev {
dimension "version"
applicationIdSuffix ".dev"
}
uat {
dimension "version"
applicationIdSuffix ".uat"
}
staging {
dimension "version"
applicationIdSuffix ".staging"
}
prod {
dimension "version"
applicationIdSuffix ".prod"
}
}
This adds a applicationIdSuffix to your builds which means that you can install multiple types on to your device. Using flavors is a really powerful way to manage your android applications. You can read more about using flavors here
One important point to note is that using flavors does change how you have to run your application.
Instead of using react-native run-android I now have to use react-native run-android --variant=devDebug.
When I want to build it instead of using ./gradlew assembleRelease, I have to use ./gradlew assembledevRelease (you have to change this for each flavor that you use)
There is also a small bug with react-native that when using the --variant flag it doesn't launch the app, so you just have to click on the icon on the device. But if you launch it from Android Studio it launches just fine.
So if you launch your application from Android Studio, or add the appropriate scripts to your package.json these issues melt away.
1 I don't use Expo for my production applications, only for prototyping, so these solutions are for full react-native applications with access to native code.
2 I use Bitrise to build my apps so it is easy to add bash scripts or similar to the build process.
If you want them to download the apps from stores then apps have to have different package/applicationIDs.
I've worked on a react native project recently and we actually handled staging and production apps in single branch. Although we didn't release staging app on play store, we were sharing using Google drive and since both app had different packages, it was possible to install both of them together.
To change the applicationId, you need to make changes in app's build.gradle file in Android. Simply add .demo or .anything at the end of your production applicationId. And also change your api end point and App name and icons if you'd like. So this becomes cumbersome doing manually after sometime because you have to change back and forth. So we wrote a shell script to make all these changes before building the apk.
We actually didn't need to install 2 versions on iPhone, so we didn't do anything about it. Also I'm not familiar with iOS development but I guess process will be somewhat similar.
Now we don't have to keep track of changes from one branch to another. Setup(Shell scripts) will take some but it will be worth it.
I'm using react-native-code-push for my app.
I had released several versions that change only a few of js bugs, which worked fine.
Recently I realized that if a code pushed release involves any change of native code other than javascript, the app crashes while updating. I added several react native packages that need manual linking such as react-native-maps, and released update to some targeted versions hoping them to take those, but no luck.
Then what if an update only involves adding light libraries (using npm install) which don't require native linking? I wonder to what extent exactly the code push allows client-side code updating.
Basically, when you want to add some native code involving link you will have to rebuild your apk / ipa and re-upload it to the stores. If you want to add a new plugin without link there should not be any problem
One advice I could give is to only push bug fixes to your production app. You should not push new features with codepush since apple review (almost) all the applications.
Have developed an app in RN and not sure if this is a problem in the RN build process or an ID10T error on my part.
One of the views needed to be able to add events to the device calendar, and none of the modules I could find online were cross-platform, so there was an Android and an iOS specific module for each.
When working in dev mode everything is perfect, but as soon as a build a release version the app crashes on load, and after a lot of testing I determined it to be simply that this non-Android package was listing in the package.json.
The package dev was not able to help, but at the same time I cannot imagine it is the package itself that is causing anything wrong, there are no references to it anywhere within any of the android files, the buttons are only loaded if the device is iOS and they are not on the initial screen.
Is this a flaw int he RN build process or is there some additional config/exclusions I need to setup.
Other than adding new modules into the required locations for android/xcode the setups are pretty much as I got them out of the box and as best as my google fu reveals nobody seems to of reported this issue before
For interest the iOS calendar module is https://github.com/wmcmahan/react-native-calendar-events.
These kinds of problems are very common when developing applications with the node ecosystem
this non-Android package was listing in the package.json
and
there are no references to it anywhere within any of the android files, the buttons are only loaded if the device is iOS and they are not on the initial screen
Looks like you are not looking in the right place or searching the right way.
Standing in the project root
fgrep -rlo "string literal" . | grep -v "ios" replace "string literal" with the module that is being loaded in the wrong platform and you will find all occurrences of this string in the files.
If this doesn't help you find your issue, there are lots of things you can try but you will have to provide more code.
When I run calabash-android, it appears to push the apk to the device for every feature file. I would prefer to push the apk once and reuse it, as each push takes about half a second, and I expect eventually to have enough feature files for this to matter. I'd be happy with a solution which doesn't push the apk at all and to push it myself in an earlier step.
Is it pushing the app each time or just restarting the app? My tests restart between each step by default but I have always had to control the installations.
I deal with the installation by tagging the scenarios that require a reinstall and looking for the tag in my before hook.
If it is the restarting between scenarios that you want to control then you can use the RESET_BETWEEN_SCENARIOS setting.
I tried to remove an iOS8 today view extension from my iOS App in Xcode6, but somehow the extension is still built and always appearing on the device. I removed both the extensions files from the project as well as the build target. I also removed the application multiple times but the widget is still always copied whenever I build the application.
If you want to keep the sourcecode and only remove the today widget:
go to your app target into your project file
select General -> Embedded binaries
remove the TodayWidgetName.appex file with the minus button
do a clean
If you compile or archive you should not see any longer the today widget appearing in the iOS notification center.
I finally found a solution: in the menu go to Product > Clean and the extensions that are not used or built anymore are gone!
Apparently, there is a way of removing embedded binaries from compiled IPA package if you don't want to recompile. Obviously, after altering the package you'll have to resign it.
This is where embedded binaries are placed:
Payload > .app > PlugIns > .appex
I've tried removing the PlugIns and resigning the whole bundle - seems to be working well.