I have updated mac to 11.6 and xcode to 13.0. Realm could not compile so I updated it with carthage to v10.15.1. Now I get this runtime error just after the app launch:
Library not loaded: #rpath/Realm.framework/Realm
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/RealmSwift.framework/RealmSwift
Reason: tried: '/Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/Realm.framework/Realm' (file does not start with MH_MAGIC[_64], file does not start with MH_MAGIC[_64], fat file, but missing compatible architecture (have 'x86_64,i386', need 'x86_64')), '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/Realm.framework/Realm' (no such file), '/usr/lib/swift/Realm.framework/Realm' (no such file), '/Users/username/Library/Developer/CoreSimulator/Devices/33E61712-D8A9-4D7E-A260-5C096BE08A82/data/Containers/Bundle/Application/AC700919-F431-446F-8BEF-FF8D8E5F5BF9/appname.a
I guess the key part here is file does not start with MH_MAGIC[_64], but I could not find anything useful about the error.
I tried embedding the library and turning off the embedding, does not affect anything.
Realm has 3 targets configured to be built with Carthage (Realm, Realm iOS Static and RealmSwift)
XCode 13 deprecated a setting for building targets in a manually set order which leads the first 2 targets to be built in a non deterministic order (the 3rd one is always last as it depends on the 1st one). The order and the frequency of it changing seems to be random (it might depend on the specific XCode version)
When 'Realm' is build before 'Realm iOS Static', the fat framework replaces the one in the xcframework which leads to that error. In the other case, it's the correct one that's built second and overrides the wrong one.
I guess the solution (apart from upgrading Realm) would be to remove the target 'Realm iOS Static' from the project but it's not straightforward to do with Carthage except by forking Realm
The latest version of realm is v10.32.0. xcode 14.1 is also out.
You need to update your toolset.
The latest upgrade realm version 10.32.0 is compatible with XCode 13.1 and above. If you use the legacy build system, migrate it to the latest one and clean the derivable folder before rebuilding the code. Most of the time derivable keeps track of the older version files and makes conflicts once you update the project tools. Hope this will help
Related
This has been killing me for the last couple of days. I have read everything I can find on this error and have done what xamarin says but it still doesn't work.
I can't get my builds to get through azure pipeline xamarin.ios build and deploy to apple.
When I build locally I get messages like
MTOUCH : warning MT1502: One or more reference(s) to type 'UIKit.UIWebView' already exists inside 'Xamarin.Forms.Platform.iOS, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' before linking
with a companion message that says no references after linking
when I use --warn-on-type-ref=UIKit.UIWebView with the optimize arg.
When I build on azure in my pipeline, I only see the MT1502 but nothing saying anything after linking. The build gets submitted to Apple and fails because of the ITMS message.
I don't know what to do. I am using the latest macOS vm image, mono 6.8.0.123, xamarin.ios 13.16.0.13, xcode 11.4.1. The pipeline worked fine before April 30 deadline, now no matter what, I can't get the linker to strip UIWebView.
Let me know what other info would be helpful. I am completely stuck at this point.
Thanks.
I just got my build to pass Apple's inspection.
What ended up working for me was building locally and packaging the ipa file. On my mac I then changed the ipa extension to zip and unzipped it. I used terminal to go to the YOURAPPNAME.app "folder" and used grep -r UIWebView . to search for references. Don't forget the . so it searches the current directory. I missed that at first and got some message that grep was listening on stdin.
For me that resulted in a line like this:
Binary file ./Frameworks/PersonalizedAdConsent.framework/PersonalizedAdConsent matches
Now, the important thing to note is the linker never warned about this, so I was completely unaware of it. In my case it was part of Firebase/Admob. I was only one release behind and updating to the latest fixed my problem.
I still am using --optimize=force-rejected-types-removal --warn-on-type-ref=UIKit.UIWebView -warnaserror:1503 as my mtouch args. But builds now get through.
I hope this helps point you guys in the right direction, I've spent the last 3 days just trying to get builds to upload reading every post I could find on the web on this problem.
Solved !! I had to update the way how nugets are included to the iOS project .csproj file. The problem was that linker despite the --optimize=force-rejected-types-removal flag was not removing the UIWebView component form Xamarin.Forms 4.6 probably because it did not see it.
My project was created over two years ago and I was still using the packages.config file. After the update the flag started to work and grep query returned 0 :). The best way is to compare the old .csproj file with freshly created iOS project .csproj file and see how VS is referencing nugets.
So I updated to swift 3.0 and now my projects with realm 1.0.2 all give me an error.
RealmSwift compiled with older version of Swift language (2.0) than previous files (3.0)
I also tried to build a net new project and still get the build error, so I know it is not a conversion issue on the Swift side.
I found several Swift 3.0 beta users and tried to run the script to update my version to 3.0 and several other options. The last few posts appeared to use Cocoa Pods - which I don't currently use. Is that the supported fix path?
Any help or direction would be greatly appreciated.
I haven't tried it yet, but here is what should work.
Essentially, the compiler gives you a description of what went wrong. The framework was compiled with Swift 2.0, while your project or other files were compiled with Swift version 3.0 (which means you made the switch after upgrading to the new version of Xcode.
To fix this, you need to use the Realm framework compiled with a Swift 3.0 compiler. Since the Realm team doesn't yet provide a precompiled version compiled with Swift 3.0, you have to do so yourself. To do that, go to their Github repository, and follow the instructions in the README under "Building Realm":
Prerequisites:
Building Realm requires Xcode 7.3.
Building Realm documentation requires jazzy
Once you have all the necessary prerequisites, building
Realm.framework just takes a single command: sh build.sh build.
You'll need an internet connection the first time you build Realm to
download the core binary.
This should generate the Realm framework with the current compiler version, which you then just have to use to replace your current Realm framework with. After that, everything should compile as it used to.
As stated before, I don't know if this actually works, as I haven't tried it yet. I don't exactly know if Swift 3.0 is supported by Realm yet or if there are any other issues you could run into. So please let me know how this works out!
I'm developing an app which is iOS 4 compatible, so my deployment target is set to iOS 4.0.
Whenever I drop a UINavigationController onto a UITabBar, I get these two warnings:
warning: Attribute Unavailable: Defines Presentation Context is not available prior to Xcode 4.2.
warning: Attribute Unavailable: Defines Presentation Context on iOS versions prior to 5.0.
The UINavigationController functions as expected, in fact, the entire app runs perfectly. But these two warnings are driving me nuts!
Also, the moment I delete the UINavigationController the warnings disappear.
Just uncheck the "Defines Context" checkbox in the attributes inspector. (Double-click on MainWindow.xib, select the navigation controller, then go to View->Utilities->Attributes Inspector.) That'll get rid of the warnings.
You are getting these warnings because you are using iOS 5.0 SDK features with a 4.x deployment target.
All, if not, most of the new 5.0 hotness, including ARC and Storyboards, is completely backwards compatible with iOS 4.x (I don't remember if 4.0 or 4.3 is the lowest supported version, check the docs), it will work as intended, but Xcode is going to warn you anyways.
You should be able to disable that warning if it really bothers you, but I wouldn't. That said, Apple does not currently accept applications built/archived with the Xcode 4.2 beta for submission to the App Store. This means you need to use Xcode 4.0/4.1 in a production environment.
Before we go any further, you should know that Xcode 4.2/iOS 5 is beta software, it is under NDA (you agreed to this when you joined the Apple developer program) and cannot be discussed in the public domain. This means you won't be able get much help from places in the public eye, like StackOverflow, as good as it can be. But, since I'm here and this is a very high level question, I can help :)
In the future, if you have iOS beta questions or issues, you should hit up the Apple Developer Beta Forums (an excellent resource, always search before you post), or #iphonedev on irc.freenode.net for not-beta stuff (I'll be there, say hi!)
If you're developing an application for release on the App Store:
You need to be developing with Xcode 4.0 or 4.1, Apple will not accept applications built/archived with 4.2. (I know I repeated myself, but people seem to miss this often)
And, although 4.2b7 supports developing for older frameworks better than previous Xcode betas have (by allowing you to install previous versions of the simulator), you will still find yourself accidentally using 5.0 SDK functions all over the place, as the code completion/interface builder very aggressively favors all of the new hotness. This is because the beta is for trying new things, not stable application development.
This means you need to switch back to using Xcode 4.0/4.1 for production, if you don't have it installed, or you overwrote the stable version with the beta, do not try to install 4.0/4.1 on top of the 4.2 beta, weird things will happen and both versions will start acting really weird and and Xcode will crash at least twice as often.
The best thing to do in this situation, is to follow the below steps. Make sure you don't skip anything, otherwise you'll have to restart the whole process.
Make sure you have your code committed and pushed up,
uninstalling Xcode like this temporarily removes git. (This was an
issue for me at work once)
Download the installers for Xcode 4.0/.1, and 4.2 if you intend to keep experimenting. (if you already
have both downloaded, this whole process won't take more than 5
minutes on an SSD)
Uninstall the Xcode beta from the command line using this command:
sudo <Xcode>/Library/uninstall-devtools --mode=all (more info here)
Restart your computer (this is important, do not skip it!!!)
Install the most recent non-beta version of Xcode and resume development.
If you want to use both versions of Xcode (4.0/4.1 and 4.2):
You must install the beta AFTER 4.0/4.1 is installed, otherwise you will be overwriting new things with old things, and this will give you many, many obscure headaches. I also recommend restarting between installations.
You need to install 4.2 after 4.0/4.1, and to a different folder (I use /Xcode4beta/, don't put it within the folder that contains 4.0/4.1, either). I've found I learn about the new hotness best if I keep separate iOS5 branches of my work, and update what I can when I have some free time.
If you have the iOS5 beta installed on your phone, and Xcode 4.0/4.1 won't let you build to your phone:
This is because Xcode needs to grab the debug symbols from the phone before it can be used for devleopment, but only the Xcode beta can do this for an iOS5 beta device, so follow these steps:
Make sure your phone is plugged in and turned on, and that your provisioning profile/certificates all check out.
Close the project in Xcode 4.0/4.1.
Open the project back up in Xcode 4.2, and check organizer. You should either already have a green dot next to your phone (assuming all of your provisioning is working), or it should be gathering the debug symbols. Let this finish, and then build your project. It doesn't need to be a successful build, nor do you have to install the application to the phone, sometimes you don't even need to build, Xcode can be a fickle mistress.
Close the project in Xcode 4.2.
Open the project back up in Xcode 4.0, you should now be able to build and install to your phone as you normally would.
Xcode 4.0/4.1 should now be able to use your device for development until you restart the computer.
Resolution is here:
How can I fix "Freeform Size simulated metrics are not available prior to Xcode 4.2" warnings?
You just need to change the development version of your xib file to Xcode 4.2 (default is Xcode 4.1)
View Controller and Navigation Controller setting or options name ( attributes inspector )
Define Context ( Checked ) unchecked.
I recently started a project using Xcode 3.2 and the vstsdk 2.4 and then I purchased Xcode 4. When I open the project within Xcode 4 I get the "missing base SDK" error which I can fix by changing that to either Mac OS X 10.5 or 10.6. After this though my .vst file is still red in the file tree. I have also tried to delete the file and re-add it but when I do it adds it as a folder instead of a .vst file. Without this I cannot build the project as the target is missing.
Any ideas?
Cheers.
The file "yourplugin.vst" (or whatever it's named) in the Xcode group is actually the product's output target, so you shouldn't delete it. If it's red, that simply means that you haven't built the target yet.
If you are using source control, I would advise reverting back to the version before you deleted the .vst file and trying to build from that point. If you're not (and why aren't you?! ;) ), then you can try re-creating the target manually.
I have also written a tutorial on how to make a VST plugin in Xcode which you might find useful. I will be updating this for Xcode 4 soon, so if you run into any problems, post a comment there.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.