I built a very small app in swift using objective-c cocoapods.
I can build it on my phone, but every time I try to upload it on testflight, I receive an email with a message saying that:
This bundle is invalid - The file extension must be .zip
Any idea what could possibly cause that?
This problem is caused by having spaces in the build source path that the Pods-frameworks.sh script attempts to check for symlink status. For example, this path references a build scheme called "MyApp QA", which causes the -L check to fail with binary operator expected, and ultimately copies the symlink file instead of the actual framework files:
/Users/me/Library/Developer/Xcode/DerivedData/MyApp-ecinfzhnelbxxegrpzcpwnezmvot/Build/Intermediates/ArchiveIntermediates/MyApp QA/BuildProductsPath/QA-iphoneos/Pods/ActionSheetPicker_3_0.framework
The easiest way to get around this is to make sure that nothing in your build path has spaces. This includes your app name, scheme, build config, etc.
A pull request has been merged to fix this, which will resolve the issue when the next version of CocoaPods is released.
Related
I'm writing a react-native app, and I want it to deploy with a zip file that contains a device firmware update.
Before letting the user send the update, I need my code to open the zip and do some validation of its contents.
I've found lots of zip-handling NPM packages, so all I need to do is load the file contents so I can feed it to one of these.
require('./firmware/fw.zip'); <-- packager doesn't include .zip by default
require('./firmware/fw.pdf'); <-- [gross hack] packager includes pdfs, but the actual result of the require() call is a number: 5. I don't know what I can do with this number to get file contents, but I'm pretty sure this require() system is designed for loading images, not binary data.
ReactNativeFs.openFile('./firmware/fw.zip'); <-- fails with ENOENT
ReactNativeFs.openFile(${ReactNativeFs.MainBundlePath}/firmware/fw.zip); <-- MainBundlePath is undefined on android.
This seems like a really basic question, so I'm sure I've missed a piece of documentation somewhere, but I'm heading into my third hour trying to load the contents of this file with no luck.
I'm pretty sure I could manually put the zip file into the appropriate android and ios resource directories, but that seems like a step down a hard-to-maintain road.
I encountered this problem again a couple months later (I'm apparently the only guy that needs to package .zips in react-native), and the above answer didn't work out for iOS. So I encoded the .zips as base64, put them in .js files, then used import to get the data from those .js files. This actually seems like a somewhat hacky but also flexible long-term solution, without having to mess around with platform-dependent file locations.
See whole answer at my new question: React-native packager configuration - How to include .zip file in bundle?
Partial solution:
Modify android/app/build.gradle, and add
task copyData(type: Copy) {
from '../../firmware/fw.zip'
into 'src/main/assets/raw/firmware'
}
preBuild.dependsOn copyData
This will at least ensure that the file gets copied each time you build, and is then available with ReactNativeFs.readFileAssets('raw/firmware/fw.zip', 'base64'). I'm not entirely thrilled because I still have to have iOS/android dependent code when loading the file, but at least it's loading now.
Tip: watch out for your syntax in gradle. into src/main/assets/myFirmware.zip will create a DIRECTORY called myFirmware.zip, and put your zip file underneath it. Then readFileAssets will still fail because it's finding a directory at your path, not a file.
I have an OSX app that needs to be able to zip and unzip directories, and I figured it would be easy using a cocoapod. I've hit a brick wall.
I've installed Godzippa, Objective-Zip, zipzap, ZipKit, ZipArchive, SSZipArchive, and basically every other cocoapod that claims to provide "Zip" functionality, but I've failed to get any of them to work.
I'll share the steps to my failure, and perhaps someone will correct me where I've strayed the correct path:
1. Because I am working out of a Swift codebase, I created an Objective-C-Bridging Header, and set the corresponding attribute under Build Settings in the Swift Compiler Section.
2. I installed cocoapods in the application and included the desired cocoa pod in the Pod file, ran pod install, and restarted the application using the workspace.
3. Inside the bridging header, I imported the necessary objective-c headers of the corresponding cocoa-pod so I can use them in Swift. For example, for SBYZipArchive I had the following in my file I imported the < SBYZipArchive/SBYZipArchive.h> header.
4. I try to build the application and it fails on multiple places all referencing the zlib.h library.
5. I attempted to provide access to the zlib library by adding the libz.dylib to the Build Phases under Link Binary with Libraries.
6. I attempt to build the application, and it still doesn't love me.
To my knowledge the reason why none of these frameworks is working is because they are for some reason failing to access the zlib files that are necessary to do the actual data compression. Thats as far as I've figured out... Any help would be appreciated.
Update
I was able to do the zipping without using any of the above packages by simply setting up an NSTask. For those who may care more about zipping than they do using these tools here is how I did it:
var task = NSTask()
task.launchPath = "/usr/bin/zip"
task.arguments = ["-r", "/Users/$USERNAME/Documents/$PATHTODIR/zip1.zip", "/Users/$USERNAME/Documents/$PATHTODIR/filesToZip"]
task.launch()
When using NSTask you set the launch path to the tool you want to use, and then give the required arguments. so the above task is the equivalent to the command in UNIX:
zip -r /Users/$USERNAME/Documents/$PATHTODIR/zip1.zip /Users/$USERNAME/Documents/$PATHTODIR/filesToZip
Obviously swap out the variables I put in there for your own path
UPDATE
Although the UNIX zipper works perfect for the mac app, I am pretty sure I need one of the zip packages to be able to do this on iOS
I have switched my XCode version from 3.2.6 to 5.1.1, I have been asked to change the project settings and porting to a new format and resolved many compilation errors as well.
Now there is no compilation errors i could able to build my project successfully.
When I tries to sign the project using codesign v2 (mac 10.9.5) i could see the following error
"Abc.app unsealed contents are present in the bundle root"
To Resolve I have gone through the below link and tried to create a bundle structure as mentioned in it, but i'm missing something basically I don't know what it is.
Codesign: What are unsealed contents?
My folder Structure would be similar to below, if anyone has seen discrepancy kindly mention what i need to correct.
/src/Abc/
Abc.xcodeproj
build\
doc\
English.proj
Info.plist
Installer.pmdoc
InstallScripts\
Japanese.lproj\
Libraries\
Abc_Prefix.pch
Abc.pmproj
Package\
Resource\
*.png, *.icns, *.jpg, setting.plist
Source\
Uninstall\
zh_TW.lproj\
In my experience, this error message means I've left some files in the same folder level as the Contents folder.
Everything must be inside the Contents folder.
Try moving whatever files are on the same level as the Contents folder to somewhere inside the Contents folder.
When I create a new project in XCode 6.0.1, I got this error message: The file "exclude" doesn't exist
It seems to only impact the versioning of the files i.e. the generated stub files are not committed into github after the project is created.
What can cause this problem?
For me the issue was caused because I had previously created a project with the same name, and Xcode still had record of that.
To clear it out,
go to Window -> Organizer in the menu bar
Remove all of the repositories highlighted in red
To add your repository (if it's not being tracked for some reason),
Click the + (still in Window -> Organizer from the steps above)
Enter the path of your file
Make sure to change to Git from Subversion (if Xcode has Subversion set as default - it did for me.
I usually get this error if I initialize an Xcode project with a git repository, delete it and try to recreate it with the same name (casing doens't appear to make it sufficiently 'different'). Turns out, "Well I'll just start over" can leave some issues as well.
Hope this helps.
I had this issue as well, and I tracked it down to the .git-template folder included with Thoughtbot's dotfiles. Basically, Xcode expects its template folder to have info/exclude, and Thoughtbot's dotfiles don't. Creating that directory and file fixed the problem, as so (in the Terminal):
cd ~/.git_template
mkdir info
cd info
touch exclude
If you're getting this issue without Thoughtbot's dotfiles, you could probably look at ~/.gitconfig and use whatever templatedir is getting set as instead of ~/.git_template in the first command.
If I try to build an application with the application class outside the default package, so the application file path is /app/AppClass.mxml instead of /AppClass.mxml (as would normally be the case), Flash builder cannot launch the application for debugging because it is looking for the SWF in debug/app/AppClass.swf and the SWF is being output to debug/AppClass.swf instead. Changing the output folder to debug/app makes it put the swf in debug/app, but then it puts the application configuration file "AppClass-app.xml" in /debug/app/app and then that can't be found.
Is there a way to change only the SWF output folder, or the location of the xml configuration file in the run-configuration?
You may use symbolic link to created swf file - http://en.wikipedia.org/wiki/Symbolic_link
for example for Windows :
cd project/path/bin-debug/package/path/
MKLINK ClassName.swf project/path/bin-debug/ClassName.swf
and it's work
or you can use symbolic link for folder:
cd project/path/bin-debug/package/
MKLINK path project/path/bin-debug/ /D
I think I remember this worked for me. But it was long time ago. And, yes, it is a known problem, I also recall Adobe people mentioning it as a limitation of FB.
In my Ant script, you'll need to do the adjustments to reflect your actual file names and directory structure. Also note that it will make it more cumbersome to debug it from FB. You'll need to use the debugging target in Ant, and then connect the debugger to the running application (so that some info, especially on the startup) will be lost. The only way you would be able to debug it, though I've never tried it, is with the commandline tools (I'm not sure of adl syntax for breakpoints / printing / stack frames, so idk how to do it.
Also, for the released application you will probably want to change the signing mechanism.