I saw this as part of the logs generated by Gradle when building an app in release mode in flutter. Does this have any side effects on the overall app?
libflutter.so is already the compiled form of flutter framework and other native scripts needed to run your app.
More specifically *.so files includes Dart language dependency, skia engine, flutter framework, platform related native code etc.
So their is no need to break them and compile them as they are already compiled. Hence it shows the message that cannot strip them packaging them as they are. This doesn't have any side effects. (*.so files are compiled form of code that are designed to run on linux distributions.) Android is also a linux distribution.
Hence there is no side effect on the app which you are building.
I read somewhere that Flutter compiles its code to ARM binaries. These ARM binaries can be understood by both ios and android and thats how flutter achieves cross-platform. If so where can we see ARM binaries? Are APK and ARM binary the same?
Can someone share some more details on it?
Here's an explanation about the comparison of dart's compiled binaries and android's apk. The page also has explanation about iOS platform compilation with Flutter. This paragraph also talks about how the Flutter VM is used, just in case you wanted to know about the JIT compiler. https://docs.flutter.dev/resources/faq#run-android
The engine’s C and C++ code are compiled with Android’s NDK. The Dart
code (both the SDK’s and yours) are ahead-of-time (AOT) compiled into
native, ARM, and x86 libraries. Those libraries are included in a
“runner” Android project, and the whole thing is built into an .apk.
When launched, the app loads the Flutter library. Any rendering,
input, or event handling, and so on, is delegated to the compiled
Flutter and app code. This is similar to the way many game engines
work.
During debug mode, Flutter uses a virtual machine (VM) to run its code
in order to enable stateful hot reload, a feature that lets you make
changes to your running code without recompilation. You’ll see a
“debug” banner in the top right-hand corner of your app when running
in this mode, to remind you that performance is not characteristic of
the finished release app.
When I build a Windows version of a Flutter app it creates a
build\windows\runner\Release\data\app.so 6MB sized file.
Obviously it an Linux ELF library yet deleting or renaming the file makes the EXE fail to start.
What kind of sorcery is this?
As answered in Github:
"Flutter applications that are AOT compiled us a .so on Windows, Linux desktop, and Android. This file contains only your Dart code. Separately, the executable is compiled from the platform specific entry point in the windows directory, along with your plugins and this depends on a dll (flutter engine) which contains the actual engine as well as the support for loading AOT compiled Dart code."
Every time I do flutter build, I get a file change in
ios/Flutter/flutter_assets/kernel_blob.bin
After committing and rebuilding then I get a lot of conflicts because of this file.
What is this file? Should I .gitignore this?
The short answer is that this file is a Dart kernel bytecode representation of your app's code generated by a compiler in Flutter's toolchain. When your Dart code changes, you should expect the built kernel_blob.bin to also change.
In a bit more detail, the flutter tool is responsible for managing the build pipeline for your Flutter app. Since your example is an iOS example, I'll describe an iOS build. During a compile via flutter build, the tool does the following:
Compile source to Dart kernel bytecode: the flutter tool locates your app's main entry point (by default lib/main.dart) and hands it to the Dart kernel compiler. The kernel compiler traverses the import graph, and emits kernel bytecode to kernel_blob.bin.
Compile kernel to ARM assembly: In AOT builds (profile or release mode), the kernel bytecode is then handed to the gen_snapshot tool, which on iOS emits ARM assembly code (we do this twice, once for 32-bit and once for 64-bit).
Compile assembly to an iOS framework: The assembly code for each bitness is compiled into an iOS shared library (.dylib file) using the clang compiler. We then use lipo (part of Xcode's toolchain) to merge the two .dylibs into a universal binary and wrap it up as a framework, including verison info, Info.plist, etc. This is emitted as App.framework.
Generate the iOS .app bundle: The native bits of your app are compiled into an iOS .app bundle. Both App.framework (your app) and Flutter.framework (the Flutter engine/runtime) are bundled into the app's frameworks directory.
Install the app to the device: The .app file is installed to the connected device and optionally launched.
You should ignore this file (and the rest of the build directory) in your .gitignore.
I know about Monotouch and I have virtual MacOS and Monodevelop/Monotouch installed.
However, is it better to build an iPhone application in Monotouch on Mac OS X or it's as easy as to build iPhone app in Visual Studio and port it to iPhone via Monotouch?
Is there anyone who tried porting c# project to iPhone? How different was it from building the app on mac os using monodevelop/monotouch?
ps. my favourite helper utilities does not exist on mac os and that's the reason for this Q
As mentioned, to compile your applications and upload them for appstore use, or debug using the simulator you'll need to use MonoDevelop on a Mac.
However it is possible to write a large portion of the code in Visual Studio 2008 or 2010.
I've written 6 Monotouch apps that are selling badly in the appstore, using primarily Visual Studio. The reason I use Windows and VS2010 is I'm a lot slower with the Mac keyboard, have my Visual Studio setup for speed, and a PC that is about twice the processing power.
Here's a few gotchas and tips:
Copy the monotouch DLLs from your Mac to Windows (search for "monotouch.dll" on the Mac), stick all the DLLs in a static place and reference them in your project. It should then compile in VS.
Make sure you keep 2 project files - a MonoDevelop and a Visual Studio one. I tried converting manually and also wrote a converter to go between the two but it breaks so often it's easier to just keep two files.
You can also convert the Mono XML documentation (it's in a different format to the Microsoft .NET XML documentation format) for Visual Studio intellisense. The link below has a download for the XML documentation I generated for Monotouch 2.1.
Avoid using a shared drive for development. This make compilation on the Mac very slow - stick to copying the files using a USB stick or ideally use an online source control site like bitbucket.org
I found it was quite fast with a single keyboard, monitor and mouse and a KVM switch going between PC and Mac.
For the layout (either XIB or C#) you'll have use your Mac, or write the bare bones in VS first.
I've written a fair amount on the process here.
You simply can't develop a MonoTouch application just using Visual Studio. You have to use the OSX tools to build the code and create the package for the phone. There's no way to work around that, and the easiest way to do it is using MonoDevelop.
What me and other developers have done in the past is to develop some of the C# libraries for the apps using Visual Studio, because even though MonoDevelop is pretty good, its still far from being as good as VS. Refactoring code, for example, is much easier with tools like Resharper, etc.
When developing the App in Visual Studio, there's a lot of things you'll have to deal with; for example:
You simply cannot run a build from Visual Studio: VS doesn't know how to build the kind of project necessary for the iPhone, and it doesn't have all the libraries that exist in the iOS SDK.
there's no visual editor to create the XIB files you you probably want to create for your app.
You'll have to do a lot of extra work here and there to get the VS to even open the solution (like copy lib files from OSX to Windows, create separate projects, etc) (although I think Novell Mono tools for VS may help a little on this one.
So here's what I've been doing for the last 6 months:
Break down the application into different projects for business logic and UI logic
You should be able to build, compile and even test the business logic from VS. Just remember not to use any UI libraries, or external libraries not available in MonoTouch
Use MonoDevelop to build the UI code part of the app. Being able to quickly run the app to test helps a lot.
Every once in a while, if you feel you need to to a big cleanup, open the code in Visual Studio, and do the refactorings; although you won't be able to build anything, the code checker in VS will help to make sure the code is still valid.
Hope it helps!
This has actually changed with new MonoTouch release rebranded as Xamarin.iOS that offers tight Visual Studio integration. You still need a Mac for building and testing but you can work from VS without much hurdle.
They even hooked up the debugger:
In this screenshot, VS and OS X run on the same computer, but they don't have to, given that there is a local network connection between them.
Read more here:
Xamarin iOS for Visual Studio allows iOS applications to be written and tested on Windows computers, with a networked Mac providing the build and deployment service.
Developing for iOS inside Visual Studio provides a number of benefits:
Creation of a single cross platform solution for iOS, Android and Windows applications.
Using Visual Studio tools (such as Resharper and Team Foundation Server) for all your cross-platform projects, including iOS source code.
Using the familiar (for existing Visual Studio developers) code editor, keyboard shortcuts, etc.
Xamarin.iOS for Visual Studio supports configurations where Visual Studio is running inside a Windows virtual machine on a Mac (eg. using Parallels or VMWare).
Note that Visual Studio integration is available in Business edition which is $999 per license.
(The license is perpetual per person but you only get free upgrades for a year.)
The MonoTouch home site states:
Please note that MonoTouch requires a
Mac, Apple's iPhone SDK and you must
be part of Apple's iPhone Developer
Program to test and deploy your
software on a device and to
redistribute your code.
I think some of the problems you are going to have using Visual Studio are
you won't be designing with the native UI controls
the emulator used for testing will be different
you may end up using API calls that aren't available in the MonoTouch libraries
I would stick with using MonoDevelop on the Mac.
Since you need the Apple's iPhone SDK (which is only available for OS X) installed to develop with MonoTouch you will be limited to developing on a Mac.
MonoDevelop is quite a good IDE, and its integration with Interface Builder and the iPhone/iPad simulator makes developing for iPhone with MonoTouch a pretty nice experience.