I have a Cocoa program with deployment target 10.7, using the latest (10.8) SDK, I run it on 10.7.5 with XCode 4.6.2. In it I work with NSURLs with no problem whatsoever, everything works fine. One method I use is the NSURL method:
[newURL checkResourceIsReachableAndReturnError:&error]
with newURL a pointer to aNSURL. So far so good.
However, when I compile and run this, on a mac mini with Mountain Lion installed the following warning appears:
CFURLResourceIsReachable failed because it was passed this URL which has no scheme
and some other things now go wrong as well, such as
[dict setObject:url forKey:[url path]],
with dict a NSMutableDictionary and url a NSURL, the url simply is not added anymore to the dict. Strange isn't it? Did I miss a change in how NSURLs work from OS X 10.7 to 10.8?
Apologies if this already has been discussed here (I could not find it), thanks for looking at this question,
Marijn
Related
My MacOS application have a child process in its resources. I launch it up by NSTask.
In local debug, everything works well. But when I upload it to AppStore, Apple told me that my child process binary need a sandbox.
Ok, I set a sandbox to my binary, but new problem came up. The process can't run with NSTask, and the error code is 4, which means EXC_BAD_INSTRUCTION.
All the thing I found is my binary need inherit its sandbox from the parent. I set these entitlements:
com.apple.security.inherit : true
com.apple.security.app-sandbox : true
Whatever, the problem still exist.
My app content is like this:
Contents
- MacOS
- mainExecutable
- Frameworks
- theFramework
- Resources
- theToolBinary
Their relationship is:
theToolBinary need theFramework to work. theToolBinary built on CommandLineTool and signed.
So, is the "com.apple.security.inherit" not working any more? Or what's wrong with my project?
I've just set up my public repository to build on Travis. It's an iOS library, that also makes use of CoreBlueooth's delegate methods. One of which looks like this:
- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary<NSString *,id> *)advertisementData RSSI:(NSNumber *)RSSI
When it is included in the code to be built, it causes Travis to fail the build due to it expecting a '>' after NSDictionary<NSString * (assumingly because it doesn't like the pointer * sign inside an NSDictionary key definition). However, this is the delegate method for CBCentralManager, so is obviously syntacticly correct.
This compiles fine on my machine, and when the particular method implementation is commented out, everything runs fine (including other CoreBluetooth delegate methods). This looks like some kind of syntax issue, but compiles fine on my end?
Turns out Travis CI defaults OS X builds to use an old Xcode version (Xcode 6.1) - as suggested by #fullofsquirrels.
This causes issues with newer syntax, and in this case caused the build to fail. Updating the .travis.yml file to specify the version to use fixed the issue, as follows:
osx_image: xcode7.2
Hope this helps someone!
Background: I decided a couple days ago that I was going to update Facebook SDK to FBSDKCoreKit from Facebook-iOS-SDK v3.24. I updated my Podfile accordingly and installed all libraries fine. I then began updating some of the code to work with the updated SDK spec.
After working on it for a short amount of time, I changed my mind and decided to rollback to the old version. I made all necessary cocoapods changes and installs, discarded all local changes in Xcode, recompiled and ran. Everything worked fine... or so I thought.
The Problem: Now, when I try to run on my old iOS7 test device, I get an error whenever the app launches. Below is the exact console output:
2015-10-15 20:14:31.271 hiatus[184:6003] [Error]: Failed to run command eventually with
error: Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be
completed. (Cocoa error 3840.)" (JSON text did not start with array or object
and option to allow fragments not set.) UserInfo=0x14d67d20 {NSDebugDescription=
JSON text did not start with array or object and option to allow fragments not set.}
After this error is displayed in the console, no Parse functionality works. Which means, in my case, that a user is unable to login. An empty error is displayed instead.
Everything works fine on iOS8, and iOS9 (simulators and real devices). I'm working with Parse v1.9. I've tried cleaning the project, resetting, etc, but without any success.
I've been able to track this down to a specific function within PFEventuallyQueue.m. It seems to occur within (void)_runCommandsWithRetriesCount:. I just have no way of knowing how to fix it.
This is a known issue with SDK v1.9.0 (https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/388). It has been fixed but not released yet (it will be part of the 1.9.1 release).
You have 3 options :
Use 1.8.5 until 1.9.1 is released.
Fix the bug yourself by making this change : https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/commit/edde3bfa8a4476ba460dddbef6f75772960e1718
Use the master branch of the git repository to get the latest commits. If you're using cocoapods you can do it by setting your pod like this : pod 'Parse', :git => 'https://github.com/ParsePlatform/Parse-SDK-iOS-OSX.git'
Now is available Parse 1.9.1 but I recommend using CocoaPods for any Framework: https://cocoapods.org/pods/Parse
I wrote a Swift App with Xcode6 Beta 2 that does some networking using CFNetwork classes such as NSURLRequest and NSHTTPURLResponse.
The App works just fine with iOS 8, still, when I try to run it on an iOS 7 device or in the simulator running iOS 7, I get the following error when starting the App:
dyld: Symbol not found: _OBJC_CLASS_$_NSHTTPURLResponse
Referenced from: /Users/patrick/Library/Developer/CoreSimulator/Devices/B0A61F43-A67C-4803-8F5D-77C3972107BE/data/Applications/E0C7C89F-9EEE-4893-BE5B-FCC224F2855D/CheckYourWeather.app/CheckYourWeather
Expected in: /Applications/Xcode6-Beta2.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk/System/Library/Frameworks/CFNetwork.framework/CFNetwork
in /Users/patrick/Library/Developer/CoreSimulator/Devices/B0A61F43-A67C-4803-8F5D-77C3972107BE/data/Applications/E0C7C89F-9EEE-4893-BE5B-FCC224F2855D/CheckYourWeather.app/CheckYourWeather
I've done some research and found out that it's a linking problem. Still, I know that the classes I'm using are already available in iOS 7.
I also tried to add the CFNetwork.framework to the frameworks in the project settings and set it to optional, which only caused the App to crash during runtime.
The confusing part for me is: I wrote a Test App and just pasted my code I used in the main app into it and it worked just fine. Therefore the code is probably not the problem.
Deleting the App from the Simulator/Device, make a clean on the project and deleting Xcode's DerivedData haven't solved the problem.
Update:
Here's the code that causes the crash:
extension NSURLRequest {
class func plainPostRequest(url: NSURL, httpBody: String) -> NSURLRequest {
let urlRequest = NSMutableURLRequest(URL: url)
urlRequest.HTTPMethod = "POST"
urlRequest.HTTPBody = httpBody.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)
urlRequest.setValue("text/plain", forHTTPHeaderField: "Content-Type")
return urlRequest
}
}
But that's just an example. Any use of CFNetwork classes causes the App to crash during start.
This is a known bug with the iOS 8 SDK. As a workaround, move Foundation.framework before CFNetwork.framework in the list of frameworks to link to in the project settings.
For me just moving the Foundation.framework before CFNetwork.framework doesn't work. I need to close and reopen the project for it to work.
I was able to fix the problem by creating a new project and copying all my classes and assets there. Unfortunately I couldn't find out what the actual source of the problem was.
Any alternative solutions are greatly appreciated!
Moving Foundation.framework would not help so after further investigation the further method helped me.
I was able to resolve the problem by adding main.m file at Build Phases -> Compile Sources
Apparently it couldn't find the main.m file.
Are there any alternatives for webkit.framework?
Is there for example a "ChromeKit.framework"? (Doesn't appear so from what I searched).
Is it not allowed by Apple to have competing browser frameworks available, or does no one simply care to make one?
Reason I ask is the appalling svg/canvas performance in webkit framework.
Edit: Found this: http://en.wikipedia.org/wiki/Chromium_Embedded_Framework
But there's no .framework available to just link in xcode 5. It also seems outdated (instructions). Anyone used this with xcode 5?
Edit: Well, I downloaded the 64-bit Mac CEF archive again today and this time it did not compile with the instructions I gave earlier. It was necessary to make some more modifications both to build settings and to source code (replacing some deprecated methods).
Updated answer:
Latest builds of the Chromium Embedded Framework 3 can be found here, the latest being from 10 days ago (2013/12/10). The Mac OS X 64-bit build includes a sample Xcode project for OS X 10.7 Lion which needed some modifications to compile successfuly on 10.9 Mavericks / Xcode 5 (see below). The build product cefclient.app is a simple bare-bones web browser.
The following instructions are for building the Chromium Embedded Framework and test apps on 64-bit Mac OS X 10.9 / Xcode 5 from the CEF release archive: cef_binary_3.1720.1548_macosx64.7z, currently downloadable from the CEF builds page. It may be necessary to Build after each source code change to show more issues.
Extract the 7z archive.
Open cefclient.xcodeproj/project.pbxproj in TextEdit and replace all occurrences of "10.7" with "10.9" (no quotes), and "10.6" with "10.9" (no quotes).
Open cefclient.xcodeproj in Xcode 5 and attempt to Build it (cmd-B).
In the "Issues" pane find "cefclient project" issues and click
"Validate Project Settings / Update to recommended settings" ->
Perform Changes. Xcode will update the project file.
Under "libcef_dll_wrapper" issues, select the issue involving
UINT_MAX, and replace "UINT_MAX" with "UINT32_MAX" in the code.
Under "cefclient_helper_app" issues, select the
"resource_util_mac.mm" subitem to jump to the source code, and
replace the deprecated AmIBundled() method with the
following implementation:
bool AmIBundled() { return ([NSBundle mainBundle] != nil); }
Under "cefsimple" issues, select the "cefsimple_mac.mm" subitem to
jump to the source code, and replace the deprecated
...loadNibNamed... line with:
[[NSBundle mainBundle] loadNibNamed:#"MainMenu" owner:NSApp topLevelObjects:nil];
Repeat step 6 for the "cefclient issues" -> "cefclient_mac.mm"
subitem.
It should build successfully at this point. Ignore the linker warnings; I couldn't seem to fix them and everything seems to work OK regardless.
To build the smaller (~80MB) release version of the cefclient:
Click the "All" target in the top-left corner of project window ->
select "Edit Scheme..."
Select the "Run" item in the left view, and choose Build Configuration -> Release.
The cefclient and cefsimple build products will be in the #{PROJECT_DIR}/xcodebuild/Release folder, while the CEF framework will be in #{PROJECT_DIR}/Release folder.
Not exactly plug and play, eh? Let me know if this works for you.