frustrations in coding no longer! Or: how I learned to stop worrying and love the MAUI splash screen

After last time, I took a break for a while and considered my options.

To review (and to help search engines find this post in the hopes it will help someone else), the problem was that my MAUI app would launch on my iOS device (a real iPhone, not the simulator), but there were black bars on the top 15% and bottom 15% of the screen, as if it were running on a smaller phone or something.

I knew the app already worked fine on Android, so it must have been something iOS-specific. The main screen of the app is a TabBar, which is a little complicated, so I got rid of it and just used a simple view. That didn’t help.

Then I had the bright idea to make a fresh MAUI example app and see if it had the same problem. I assumed that it wouldn’t, and I could use it as a known-good template to look at for reference. Unfortunately I could not for the life of me get it to build and deploy with the paired Mac – every time I tried I get the infuriating “Verification of iOS environment is running. Please try again in a moment.” message, and restarting both laptop and Mac didn’t fix the problem. I guess it’s a problem with that project, since I rarely see that problem with my real apps, although it’s pretty weird/bad that it happens with an simple example project!

Anyway, this at least let me compare a bunch of iOS-specific stuff (project settings, Info.plist, and such) to something I assumed worked, and I tweaked a few things to match that seemed like they shouldn’t make a difference. And they didn’t!

Then I started thinking about the splash screen. As I mentioned in the last post, I had a heck of a time getting the splash screen to work right in the Android version of my MAUI apps. What I had in the pre-MAUI version was a .png splash screen which I knew might be resized or centered, but I was fine with that. The MAUI splash screen documentation says that “A .NET MAUI splash screen can use any of the standard platform image formats, including Scalable Vector Graphics (SVG) files.” So I thought “great, I don’t care about the splash screen that much, I’ll just stick the .png in the right spot, mark it as MauiSplashScreen, and call it a day!”

This did not work; the splash screen just didn’t show up. I tried a bunch of things, including converting the .png to an .svg, but no luck. So I gave up on the MAUI-based splash screen, removed them from the project, and dropped down to the Android-specific layer to put the splash screen. Frustratingly, that also didn’t work, and eventually I just gave up because I only have so much time on God’s green earth and I didn’t want to spend any more caring about a splash screen that shows up for under a second.

Aaaaanyway, I knew that I had left the splash screens in a weird state, and I had a vague idea that maybe if the splash screen was sized to only take up the middle 70% of the screen, that could cause the rest of the app to only use that space. So I removed all the other splash screen detritus and reverted back to the stock MAUI-based splash screen. Feeling hopeful, I fired up a build, deployed it, and…

Nope! Still the same behavior. I was nearing my wit’s end, so I did a clean and rebuild and deploy, and was ready to try a few minutes later, and…

Success! My splash screen theory or something like it was right. And I needed to rebuild because, umm, probably platform bugs or something 😡

But, now I know to not get cute with splash screens. (my guess is the .png to .svg converter made a weird kind of .svg that didn’t work right, or something??) And I’m reading up a little on Inkscape to make a hopefully-working .svg splash screen!

Chip War: The Fight for the World’s Most Critical Technology review

Chip War: The Fight for the World's Most Critical Technology by Chris Miller

My rating: 5 of 5 stars


Very through yet readable look at the semiconductor industry and how we got to where we are now. I knew some of this stuff but I learned a lot, and Miller does a good job of describing people’s motivations and such. It’s also very up to date, briefly covering supply chain problems in 2021.

The author is clearly in favor of a more restrictive policy about letting China use advanced semiconductor policy, and now that I’m on this Goodreads page I see he’s a fellow at the American Enterprise Institute, which tracks. I don’t think he’s necessarily wrong, though, and the CHIPS Act that Biden passed sure seems like a step in the right direction.


View all my reviews

frustrations in coding: porting Xamarin.Forms apps to MAUI

Update: I solved the problem! See frustrations in coding no longer! Or: how I learned to stop worrying and love the MAUI splash screen

I currently have two published mobile apps – Airport Guides and Baseball Odds, both of which have Android and iOS versions.

The Airport Guides app in particular has a long history – it started as FlightPredictor for webOS (RIP FlightCaster, the amazing backing service!) which I released in 2010. In 2011 after webOS was on its last legs1, I ported FlightPredictor to Android, and in 2012 I ported it to Windows Phone 7 too (it did not sell well). All 3 of these apps were complete rewrites, since webOS was HTML/Javascript, Android was Java, and Windows Phone was C#/XAML.

After this came a 2012 port to Windows 8, which sounds like it should have been easy but was a fair amount of work because it used a different flavor of XAML (not to mention adapting the UI to a full-size screen). In 2014 FlightCaster went away, so all the FlightPredictor apps2 got broken and I withdrew them all. In 2015, I took the FlightPredictor app, adapted it to use the FlightStats API, added an Azure service for background updates, and released it as FlySmarter for Windows Phone. It was not a success!

In 2016 I gave up on FlySmarter and released Airport Guides for Windows 10, which took out all the flight tracking stuff and just kept the airport maps I had built up over the previous iterations of the app. Again, the port from Windows Phone to Windows 10 was easier than starting from scratch but not trivial.

In 2017 Windows Phone also died, and I really wanted my app on my phone, so I ported it to Xamarin.Forms and released it on Android. I could reuse most of my C# code, but Xamarin XAML was similar to Windows XAML but with enough differences that it took a lot of work. (not to mention the Android-specific stuff)

In 2021 I started a fresh project and made Airport Guides 2.0 for Android. Honestly, I don’t remember why I had to make a fresh start with the UI code, but I guess things had changed enough in Xamarin.Forms to make it worthwhile. In 2022 I bought a used Mac Mini and ported Airport Guides to iOS.

Why the walk down memory lane? The point here is that I have ported the same core of an app eight times over the last 13 years. A lot of this wasn’t adding new functionality, or making it work better, but just getting to work the same way it did on the previous platform/framework. It can be satisfying to have a working app, but it’s not very fulfilling work!

In 2021, Microsoft announced that their new way to target iOS and Android (and others) was MAUI, and Xamarin.Forms would be deprecated and receive no more updates in November 2022. In 2022 I decided to go ahead and port my apps to MAUI. I started with Baseball Odds since it’s a lot simpler. I tried following a guide to upgrade the project, which kind of worked but ran into weird deploy problems I just could not fix. Thanks to Lance McCarthy, the solution was to recreate the project from scratch starting with a MAUI template, and copy code over. A pain, but a workable pain.

Doing that was enough for me to be able to ship Baseball Odds for Android on top of MAUI in September 20223. My plan was to do Airport Guides for Android next, since the memory of how to get MAUI stuff working on Android was fresh, but I ran into an impossible-looking crash in the ListView code and eventually gave up in frustration. I decided to set it aside for a while. This month I came back to it, upgraded Visual Studio and the dependencies and whatnot, and lo and behold the bug was fixed! It was tough picking up from where I left off months ago, but I finished making sure everything worked and shipped Airport Guides for Android (MAUI edition).

So next up was Airport Guides for iOS. Getting the app to compile wasn’t much work, but after I fixed the straightforward crashes on launch the app would launch and display a blank screen. Eventually I figured out this had something to do with icons, so I messed around with those and, hey, stuff showed up! The problem now is that the app is only drawing on the middle 2/3 of the screen – there are giant black bars on the top and bottom.

I’ve tried a lot of stuff but I’m kind of at a loss. At least with a crash you get some relevant info! Now Visual Studio’s Live Visual Tree mostly works, which is pretty great, but it just shows the top-level XAML element only covering the middle 2/3 of the screen and I can’t figure out why. (this is also not a very Googleable problem…)

So, I don’t know. I feel a strong compulsion to finish Airport Guides (and Baseball Odds) for iOS so all my apps are on the same codebase4. But I’m really nearing my limit for spending my scarce free time butting my head up against problems like this. I’m still running into a lot of the irritations I hit in my initial iOS ports where I frequently have to restart Visual Studio or my laptop or my Mac, wait a few minutes, and hope the problem goes away. (I do think that some of this is that the Mac Mini I’m using is quite slow, but I’m not excited about spending more money to get a more recent one…)

While gathering the posts to link here, I ran across this post I wrote in 2011 about what I want out of app development. And while the money is nice (last year my revenue was almost $1000!), after subtracting off program fees and the Mac purchase and dividing by the number of hours I spent working on the apps last year, it is not a great value proposition5. As for craftsmanship, that has really fallen off as I get frustrated and just try to get my apps in a shippable state.

I think in the past I’ve overcome a lot of this because I had more free time, and also because I could convince myself that this platform/framework would last for a while. That second point is getting harder and harder to believe; eight times in thirteen years is a compelling counterpoint! Especially when my web-based projects generally just hum along and work, modulo annoying npm dependency updates for security reasons.

1 – Wow, in retrospect webOS really did not last long! To be fair, the Palm Pre (the first webOS phone) did launch in 2009, but still… (back)

2 – “FlightPredictors app”? Nah… (back)

3 – I didn’t even post about this because there was no new functionality (unless you count “the splash screen doesn’t work because I gave up after days of frustration” 🙄) (back)

4– Not to mention I have two long-running MAUI branches in my git repo (one per app for some reason), which is a terrible thing to make decisions based on, but it bothers me! (back)

5 – One big problem is that the airport maps have to continuously be refreshed – last year I updated 72 of the 95 airport maps, and each one takes an average of an hour or so. (back)

linked list friday: fake people, fake books, teen pregnancy is way down!

(boilerplate about it having been a long time, etc 🙂 )