We have a Cordova app built with Meteor 2.9. We want to avoid updating the platform because it would kick off an expensive corporate QA cycle that would cause tons of grief ¯_(ツ)_/¯.
When the iOS app loads it displays the default Meteor splash screen, then it displays the correct splashscreen before the app is available. I am looking for any means to remove/replace/suppress the meteor splash screen. The corporate clients would rather see a white nothing than someone else’s brand.
I have replaced every occurrence of a meteor splash screen that I can find and still the same image appears.
<splash src**=“resources/Default@2x~universal~anyany.png”/>**
The Cordova build puts the wrong image in cordova-build/resources/Default@2x~universal~anyany.png, but I replace that with the correct one, as is also mentioned in the somewhat related post: Anyone got Android and iOS launchScreens to work in 2.14 - #19 by jacoatvatfree
The cordova build also puts the wrong image in LaunchStoryBoard, but if I manually replace it with the correct image, then that appears secondarily, as I described above.
I have scanned every image folder that I can find in cordova-build, and nowhere does this meteor image appear (that I’ve found).
Does anyone know where that image comes from? I’m hoping that I can surgically change the source as a workaround.
Have you tried clearing /.meteor/local cache under your main project folder?
It sounds like the default Meteor splash screen is still cached. Try cleaning the Cordova build (cordova clean && cordova build ios), and check the config.xml and AppDelegate.m for any references to the default splash image. That should help fix the issue without triggering a full QA cycle.
Adam, Your suggestion has thrilling implications. How do I run direct cordova commands in the meteor project? I’ve wanted to do that for years.
I’m trying to understand better your problem.
It seems that configuring the splash screen with App.launchScreens or App.setPreference in mobile-config.js should be enough, depending on your Meteor version (2.9). Could you share the exact contents of that configuration? Could you create a small repository that reproduces the issue, using the exact configuration and Meteor version your app runs on? If we can observe the same effect, it will help us assist you more effectively.
If you’re directly modifying the Meteor-generated Cordova project, work within .meteor/local/cordova-build and make sure to completely remove references to the Meteor splash screen. Since you’ve likely done this, I’d suggest opening the iOS app in Xcode rather than using meteor run, as the Meteor command might re-add assets unexpectedly. In my experience, modifying the Cordova project often means transitioning to working directly with the native IDE. Be aware that removing .meteor/local will wipe any direct changes you’ve made to the Cordova project, so it may help to maintain a version-controlled copy if this approach solves your issue.
For production with this custom Cordova setup, build, sign and publish using the IDE instead of meteor build to ensure your custom modifications are retained.
How do I run direct cordova commands in the meteor project? I’ve wanted to do that for years.
Meteor internally uses cordova-lib to manage the Cordova project based on the settings in mobile-config.js. If you want to run Cordova commands on the project generated by Meteor, execute them in .meteor/local/cordova-build. Keep in mind that any customizations must account for what mentioned above.
Thanks for all the great suggestions, and for all the great work of the Meteor team.
I’ve narrowed it down a bit. The meteor splash screen appears while the app is being loaded to the device. At launch, the launchscreen I configure appears. So once the app is on the device, the user never sees the meteor splash screen. I’m still perplexed about where that loading screen comes from since I’ve tried to search every single image in the meteor project, the xcode project, the cordova libraries, even the stuff cached in ~/.meteor. I know I’ve missed, just can’t figure where to look.
I’ll try to make a minimal reproduction next time I am working in the app, probably next week.
As for running raw cordova commands in the cordova-build directory, where is the cordova binary that meteor uses?
I have found the same as you–once the Xcode and Android Studio projects are created and all the settings tuned and tweaked, it is best to version control them to bring back all the customizations that get wiped the next time ios-device is run.
Just a word from a gushing fanboy. Our first meteor project was in 2012, and it has been our go-to for realtime dev ever since. We have an IoT product still in production written in 2013 in Spark, later converted to Blaze. We are a Vue team for the most part these days. I am over the moon about what you’ve done in Meteor 3.
So once the app is on the device, the user never sees the meteor splash screen
This seems more like a development mode issue, right? Your users won’t see the Meteor splash screen, as I understand from your last message. However, in your original message, it seemed like they do.
As for running raw cordova commands in the cordova-build directory, where is the cordova binary that meteor uses?
Meteor doesn’t use the Cordova binary directly; it uses an npm package cordova-lib that provides a Node API to handle all Cordova behaviors. You’ll need to install the Cordova CLI separately and ensure the version matches the one Meteor uses. For example, Meteor 2.9 uses Cordova 10. You can check this from this part of the meteor code and have selected the proper 2.9 version.
Just a word from a gushing fanboy.
It’s great to hear how Meteor has helped you shape your products! We share your enthusiasm for the tool and are excited to see its continued evolution. I’m looking forward to seeing older projects migrate to Meteor 3, or new ones built on it directly.
It seems like you’ve already tried replacing the images, but the default Meteor splash screen keeps showing up. This might be due to cached assets or build configurations. Try clearing the app cache or doing a clean build. Also, make sure your config.xml explicitly points to the correct splash image. You can also check if there’s any reference to the Meteor splash in the native iOS code. If the issue persists, it might be worth digging into the Meteor build process or checking for any related documentation.