I use Intel XDK to build an iOS Legacy App.
But XDK generates a file with an '.app' extension and not an '.ipa' extension.
Where is the problem?
Can you help me?
The legacy build system generates that .APP file. The Cordova build system generates an .IPA file. Please use the Cordova build system, the legacy build system has been deprecated and will be retired in the future.
Related
We have a project that uses many AWS libraries. On first attempting to build it, using carthage, it downloaded binaries and it did not build at all. So we ran carthage --no-use-binaries and it built the libs.
Then this error occurs:
LoginService.swift:9:8: Module 'AWSMobileClient' was created for incompatible target arm64-apple-ios9.0: ..Carthage/Build/iOS/AWSMobileClient.framework/Modules/AWSMobileClient.swiftmodule/arm64.swiftmodule
Based on this stack overflow thread, we add arm64 to excluded architectures for the simulator.
Which makes all the aws code compile (yay) but then, this error occurs trying to use a framework that is coming in via the Swift Package Manager:
[].swift:10:8: Could not find module 'Parma' for target 'x86_64-apple-ios-simulator'; found: arm64, arm64-apple-ios-simulator
So it wants the x86 version of this lib, and cannot find it.
The app does run on the phone now. But not the simulator of course. Not sure if there is a way to figure out which architectures are built by SPM? or control it. I did reset the SPM cache after excluding the arm64 arch.
I think the best solution for getting this working on M1 is to use XC-Frameworks.
carthage update --use-xcframeworks
This will only build the valid archs you need. If you have any dependencies that don't support XCFrameworks yet you'll have to run lipo to remove x86 simulator targets in your build phase.
Hey I've come across the issue. Just open your old project by Rosetta and build it. Then uncheck open by Rosetta and build it. It helped me to open old project on m1
I am writing a program in Swift using Mac OS Sierra and Xcode 8.3.2 and am using the RandomKit module from: https://github.com/nvzqz/RandomKit. I am using the basic Swift Package Manager to import the package into my project.
My program builds and runs fine, but when I go to archive it, I get an error saying "No such module 'RandomKit'
It highlights my code:
import RandomKit
Does anyone know why this would build and run but fail when I attempt to archive?
By default, when you Run in XCode, it uses the Debug configuration, and when you Archive, it uses the Release configuration. In Build Settings, look at the Build Active Architecture Only setting. By default, it is Yes for Debug, and No for Release.
This means that when you Run, XCode only builds for the simulator's architecture, but when you Archive, it builds for all possible iOS architectures.
Now, look at the settings for RandomKit to see what architectures it is built for. It needs to include all of the iOS architectures, like arm64, armv7, and armv7s.
After probably 4 hours I finally figured it out. I think this must be a bug in Xcode, but here is my workaround.
In this folder:
~/Library/Developer/Xcode/DerivedData/<My App Name>/Build/Products/Debug
I found RandomKit.framework and ShiftOperations.framework. I copied those two files into the root directory of my Xcode Project, and then linked the frameworks under General in my Xcode Project.
Linking Frameworks
This is a project which use phonegap 2.9 for iPhone app. Now I use phonegap's build tool to build an .app file, But this .app file is not signed. What I want to know is:
Can I use phonegap's build tool to build a signed .app file?
More about my project:
I have to use command line to build my project.
I have tried to use xcodebuild with param CODE_SIGN_IDENTITY to build it, but is failed with <Cordova/CDVViewController.h> file not found message.
I need you help. Thansk a lot!
To publish the in apple store at first you need to build an ipa file.
To build ipa file you need to archive the project.
Archive can be found here:
Project>Archive. (Be sure to choose iOS device in Run option).
To carry out all these task you will need provision file from your developer account.
For more detail you can go through these links:
How to get ipa file from Xcode to run an iPhone app in real device?
Deploy .ipa file in App store generated by Phonegap?
Publish Phonegap Build App at Apple's App Store - Experiences?
I'd like to use the excellent stringencoders library in an iOS application. It's a fairly typical c library, with a configure script generated by autoconf and a makefile.
What I'd like to do is compile arm7 and i386 versions on Mac OSX and then use lipo to make a fat binary.
I'm having trouble figuring out how to persuade the build tools to create my platform-specific binaries. There's a few articles out there and even a few scripts but most of them are targeted at XCode 4.2 and don't work with 4.3.
It looks like it should be possible to create a fairly generic build script that can play nicely with configure and make but I'm at a loss as to where to even start.
Have you successfully done anything like this? I'd love some pointers!
BTW: 'import all the sourcecode into your project' is NOT a viable solution. That way lies madness.
Thanks.
I've ported a handful of open source C libraries to iOS (see iOS Ports). I've found the most reliable way to port a library is to build a new Xcode project with a build target for a static iOS Library. It is important to note that Apple will not allow your iOS Application to contain dynamic libraries if you plan to distribute your app on the iTunes App store, so you will be unable to use FAT libraries.
These are the steps I usually follow when porting libraries to iOS which usually built with the GNU Autotools:
Run ./configure with appropriate flags on OS X.
Verify that the library builds correctly on OS X using make.
Create a new Xcode project using the iOS Static Library template.
Add the config.h from the previous configure run to the Xcode project.
Read the automake file (Makefile.am), and add the referenced sources in the automaker targets to the Xcode target for the static library.
Copy the CPP flags (i.e. -DHAVE_CONFIG_H) from the automake file to the build settings in Xcode.
Compile in Xcode and start running down errors (usually by adding missing header include paths or missing source files).
The directory structure I usually use is the following:
project/
project/ported-project.xcodeproj
project/project-x.x.x.tar.gz
project/project-x.x.x
project/project -> project-x.x.x
I know this is not exactly what you asked for in your question, however it is rough outline of the steps I've used for years for porting libraries. The benefit of creating an actual Xcode to compile the ported library is that it makes it easier to integrate the library into multiple Xcode iOS applications.
If you need clarification or more detailed instructions, let me know and I"ll try to write up more extensive instructions and update my answer.
Is it plausible to add the source files (i.e. .c files) to your project directly?
Objective C is a superset of C so i am surprised that the code did not work directly out of the box in XCode 4. Are you missing out something there ? just suggesting
Generate your project files using gyp: http://code.google.com/p/gyp/
I use it to share libraries between win/osx/ios and linux (pi).
I am new to Xcode and MonoTouch, so please bear with me.
Is it possible to develop MonoTouch applications with Xcode instead of with MonoDevelop? I have read the MonoTouch Xcode tutorial but unfortunately the process described does not seem to work with the latest MonoTouch version (I get a "No SDK in directory" error, there is also no resource rules file in the root SDK directory). Finally, where am I supposed to put the directives to the MonoTouch compiler?
I have downloaded the trial version of MonoTouch.
Thanks in advance.
Its technically possible, but not in the supported MonoTouch workflow, so you'd be somewhat on your own. What you'd need to do is look at the output of a MonoTouch build with "-v -v -v" in the Extra Arguments field to see how we invoke the AOT compiler. You'll also need to look at the main.m generated by -keeptemp and adapt that in to your Xcode workflow. Lastly you would not be able to use the linker unless you maintained a parallel monotouch project which compiled and linked, and then you did a secondary build step to update your Xcode project.
Xcode does not support third-party plug-ins or environments.