Build environment to run Flutter apps on iOS

This is another personal memo. There have been quite a few glitches to overcome, to run Flutter apps on my newly bought M2 mac. I want to write about them, before closing the tabs of the pages explaining the solutions.

CocoaPods

What is CocoaPods?

CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. (https://cocoapods.org/)

When you try to run your Flutter app for the first time on an iOS device (one of the simulators, most probably), the system complains that CocoaPods is missing.

OK. No problem. Let me install, following the instruction found on the above project site. Then, the first glitch. The instruction won't work. There seem compatibility issues for Cocoapods and silicon chip based M1 and M2 based macs, which prevents it from directly installing Cocoapods on these machines.

The solution is found at this page. You basically first install a tool called Homebrew, and then let it install CocoaPods for you.

Unable to boot the Simulator

It has suddenly become that I am not able to boot any iOS simulator.

You may be lucky that this does not happen on your system. But it did to me (I suspect that this is due a Xcode update, but not sure), and it took sometime to remove the problem. So it should be worth to write here what I did for future reference.

So this is what you want to do, you go to "About this Mac" > "More info..." >Developer (info icon) > Select anything that has "xcode" and "cache" in it > Click "Delete". Close all this and relaunch simulator.

error:iOS 17.2 is not installed. To use with Xcode, first download and install the platform

Now that the iPhone 15 on iOS 17.0 is running. I tried to deploy the app onto it and got this error.

I first did not understand why I need to install the iOS 17.2 SDK. I have ones for 17.0 and 17.0.1. The simulator is on 17.0. Why is 17.2 required??

Now I understand as follows. At the time of this writing, I am on Xcode 15.2 on macOS Ventura 13.6.1. https://developer.apple.com/support/xcode/ reads as below, that Xcode 15.2 requires the iOS SDK 17.2.

I installed the SDK as instructed by the error message. And finally, I can now run my app on the simulator.

_NativeStripFiles fails when building release build to upload Apple Store

I do not know if this is relatively known. This xcode-select --switch command.

Anyway, this is what happened to me. As it took sometime for me to figure this out. It is probably worth taking note.

First of all, I had multiple instances of Xcode installed on my Mac.

To be more precise, I have got a new Mac recently, a few months back. By then, the latest Xcode was 15. Naturally, I installed it.

Then I found that Visual Studio (I develop a Xamarin app) of that moment does not work hand-in-hand with Xcode15. I installed Xcode 14.3, keeping 15. They are sitting in different folders. In Visual Studio, I specify 14.3 as Apple SDK.

All went well. I built and published my app with the 16.4 SDK which comes with Xcode 14.3.

Sometime after that, I felt the need of using 17 SDK (I wrongly believed that this is required to support iOS17 devices). I found that with the Visual Studio update out in Oct 2023, I can use Xcode15 SDK (which is 17.0). The new build runs OK on an iOS17 simulator. So far so good.

To release to App Store, we need to build the app against an actual device, as you know. Then I have got this error:

xcrun: error: sh -c '/Applications/Xcode_14.3.1.app/Contents/Developer/usr/bin/xcodebuild ...

What?! Why this still tries a command of Xcode14.3, even after I have switched the Apple SDK to use to Xcode15!

I looked everywhere, Googled for a hint. No chance.

Helpless, I told myself how happens if I removed the Xcode14.3 installation folder.

Bingo! Now the error has changed and saying:

xcode-select: note: No developer tools were found, requesting install.

If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools

With this message, I have come to know that I need to run the command to tell the system the Xocde I want to use.

WebAuthenticationSession "The UIWindowScene for the returned window was not in the foreground active state."

In my case, I got this error (from a certain point of time if remember well), when implementing an OAuth protected API access upon a screen opens.

My platform is Xamarin.Forms.

Originally, I was doing so in the OnAppearing event handler. Opening WebAuthenticator browser etc. that sort of things. But at one point, on iOS, it stopped working, giving the following exception:

Error Domain=org.openid.appauth.general Code=-3 "(null)" UserInfo={NSUnderlyingError=0x60000299a7f0 {Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=3 "The UIWindowScene for the returned window was not in the foreground active state." UserInfo={NSDebugDescription=The UIWindowScene for the returned window was not in the foreground active state.}}}

It appears that the WebAuthentication browser can only be shown and return thereafter, to a foreground active window.

OK. Let us move it to another event handler which is called when the windows appeared, rather than appearing.

There seems, however, no such an event available in Xamarin.Forms, in the PCL project.

On the other hand, the iOS native UIViewController has the event ViewDidAppear, and we can code the handler through the PageRenderer.

I am still a newbie in Xamarin development, was not sure if such is possible. But wow! It works like a magic! I moved the API calling code from the page code behind class OnAppearing method to the PageRenderer. Only for iOS. For Android, it remains in the code behind class.

So the "life cycle" is, on iOS, the ViewDidAppear method is called first since there is a custom renderer is implemented, while on Android, simply only the OnAppearing method is called.

Build pipeline for a Desktop Bridged Xamarin project

By the way, I am writing this with Open Live Writer, which finally back again supports Blogger. Not officially though…

Let us start the story of the title.

An explanation for the cryptic title first.

What is Desktop Bridge? As explained here, its goal is to create a bridge between the new development approach introduced in Windows 10 (the Universal Windows Platform) and the traditional desktop application. 

In my case however, I came across this idea when I was seeking if feasible to use the systray from my Xamarin/UWP application. I want to make my app like MS Teams, which runs when you starts your PC, stays up in the systray, showing the status (your availability as it is seen by others). I found this blog post. Its sample code is found as a part of the Microsoft GitHub repo for Desktop Bridge samples. It explains how to enable a UWP package to have executables that run as full trust instead of in an app container. 

How to have an UWP app start at sign-in is found here.

I brought these ideas into my Xamarin project, have had it acts like Teams as described above. Very happy.

The next step is to establish its build process as a Azure Pipeline, so my business colleagues come directly there to find the app and test for each feature request, bug fix etc.

I am using a Cloud agent. At the beginning, it fails in building the systray component project. The project has a reference to c:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.19041.0\Windows.winmd, which is not found on the cloud agent machine.

##[warning]C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2302,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "Windows". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

Interestingly though, it appears to me that it is not that the file (part of Windows SDK if I am not wrong) does not exist on the machine, but the reference is somewhat modified…

For SearchPath "{HintPathFromItem}".
Considered "D:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.19041.0\Windows.winmd", but it didn't exist.

It is C not D, the original reference.

I struggled, and finally seems to have found a bit odd but nevertheless working solution, which is to copy the file (it does exist!) to the project’s bin folder so it is found.

Other may-be-oneday-useful info:

• As of today, on the Azure Cloud pipeline agent, four Windows SDKs are available, including the 2004 aka 10.0.19041.0 that I needed. https://docs.microsoft.com/en-us/answers/questions/863168/uwp-app-will-not-build-using-windows-latest-window.html
• How to install if it is not there. https://community.chocolatey.org/packages/windows-sdk-10-version-2004-all/10.0.19041.0
• Sign UWP app with a code signing cert stored in an Azure vault. https://github.com/microsoftdocs/msix-docs/blob/main/msix-src/desktop/sign-with-akv-cert.md
• Sign in a Pipeline https://docs.microsoft.com/en-us/windows/msix/desktop/msix-packaging-extension?tabs=yaml

Tha’s it!

Running Linux container-based apps on Windows server

It took me quite some time to finally have this running. But I am writing this to tell you that I probably made a bad choice after all...

Why I wanted to run a Linux-based app on a Windows server?? Never mind. That happens to life from time to time, doesn't it?

The idea originally came to me already back end of year 2020. I grabbed the script that we were running on a Linux server, and saw how easy it is to run it as is inside a container on my Windows laptop. That was super easy I recall. Encouraged, started the effort of deploying it onto one of our Windows servers.

Onto your workstation, you install the package called Docker Desktop. Super easy. Again.

However to a Windows server, you need to install what used to be called Docker Engine Enterprise. The installation was not a challenge. I found a lot of blog posts explaining it.

However (again) when I was in the middle of it, I found that the maintenance had been passed from Microsoft to a company called Mirantis. The most important change is that this package is no longer free. It is free, still at the time I am writing this, which is January 2022, but not after the year 2024. The devil is that when you have yourself busy with the installation following all those blogs, majority of which talk about the free Microsoft version, you would never imagine that it is becoming a paying package. By the time you found it out, you spent quite some time on it already. Going for an alternative, throwing all the time and effort into garbage is quite discouraging... 

This is the first reason that I qualify it as a wrong choice.

The second was that the capability of running Linux containers on it had been said "experimental" and the development has now stopped. Here reads as development has now stopped in favor of running docker natively on Linux in WSL2. The WSL feature is available only on the desktop edition Windows such as Windows 10 as of today, not with the server OSs. It may never be...

In addition, I recently received an email to announce that the above mentioned Docker Desktop package for your development will soon become a paying software too.

Of course, there is nothing wrong with charging users with a fee. But I do not really like this practice of allowing to start with no fee, and starting charging once users have developed a lot and become unable to operate without it. 

Debug a Release Build

Another post really for myself to keep a good pointer, and/or thing(s) learned.

I had a code in C++, which runs OK in Debug build, but not in Release build. Not running here I mean that it crashes, fails even in exception trapping. After all, I found out that it is due to a library implemented by a colleague, which exit when an exception happens in Release build, while passes the exception to the caller in Debug build.

Looking back, this could have been found, by stepping through the code in Debug build. Apparently I did not have such a patience, and found it only by “debugging the Release build”.

It turned out be pretty simple. Just by following the instruction found at https://docs.microsoft.com/en-us/cpp/build/reference/how-to-debug-a-release-build?view=vs-2017.

The step 6 says:
You can now debug your release build application. To find a problem, step through the code (or use Just-In-Time debugging) until you find where the failure occurs, and then determine the incorrect parameters or code.

At the beginning, it was not clear to me how??? But then realized that I just need to push the usual green arrow .

Building Log4cxx with VS2015

I do not think this interest many. Me myself may not come back to this again. I found it not work with my Qt app, at least as is, and so have gone to “a blend of” Log4Qt. But I spent an entire day for this, so want to leave the log somewhere...

Anyway, first of all, what is Log4cxx?

It is the C++ port of the famous Log4J. I have been using Log4Net (Not J ), so wondered if there is the same for my C++ app.

The official instruction for the build can be found here. But apparently many are having difficulties in doing it. Google “log4cxx visual studio” and you wiil see.

Let us start with downloading the required packages. # By the way, I have never succeeded in the signature checking... But no time for it now.

For apr and apr-util, newer exist. But the util package does not contain the xml VC project referenced by the main log4cxx solution. So I sticked to their versions of the instruction.

Building apr failed. This blog post How To Build Log4cxx In Visual Studio 2010 helped.

It reads: If apr fails, and you find out _WIN32_WINNT is less than _WIN32_WINNT_WINXP, ...

This was too cryptic to me at the beginning.

_WIN32_WINNT is defined as follows in the project.

#define _WIN32_WINNT 0x0400

_WIN32_WINNT_WINXP is said defined as 0x0501 in the Windows header files. ref. Using the Windows Headers

So I added the precprocessor definition as instructed.

Proceed to builing the main log4cxx project, and have tons of compile errors just as predicted by the blog post.

However, for VS2015, the solution appears not the one presented there, but the same for 2012 instead.

Thanks GOD. Now the number of compile error comes down to only one, which is removed by adding #include <iterator> in stringhelper.cpp.

Finally, there are a handful of linkage error to resolve. It says here that it has started with VS2013, Gorsh!. How to take out the function casts is detailed here.

Thanks GOD! I have got the DLL and confirmed that it works with a test win32 console app, but not my actual Qt app...