Bei mir hat die Autocompletion/Syntax Highlighting für Swift Files innerhalb meines Projekts (Objective C und Swift) nicht mehr funktioniert. Abhilfe schaffte folgender Fix von Stackoverflow:
1) Xcode schließen
2) Terminal -> rm -rf ~/Library/Developer/Xcode/DerivedData/*
3) Terminal -> rm -rf ~/Library/Caches/com.apple.dt.Xcode
4) Xcode neustarten
Quelle: http://stackoverflow.com/questions/25133039/xcode-6-isnt-autocompleting-in-swift
RestKit v0.39 hat in Verbindung mit der aktuellen CocoaPods Version bei mir zu massiven Problemen geführt. Ich habe für meine Build-Targets folgenden Fehler geworfen bekommen:
RKObjectMapping.h Not Found
Ein Eintrag auf Stackoverflow brachte mich auf den Weg, dieses Problem zu lösen
With the LATEST version of Cocoapods and Restkit : (thank's to @Alix's answer for the hint)
Go to Project Settings/Build Settings/Header Search Paths
Add these lines:
${PODS_ROOT}/Headers/Public/AFNetworking
${PODS_ROOT}/Headers/Public/Bolts
${PODS_ROOT}/Headers/Public/ISO8601DateFormatterValueTransformer
${PODS_ROOT}/Headers/Public/RKValueTransformers
${PODS_ROOT}/Headers/Public/RestKit
${PODS_ROOT}/Headers/Public/SOCKit
${PODS_ROOT}/Headers/Public
And make all of them RECURSIVE
Link: Stackoverflow
Ich habe aktuell ein Problem mit RestKit und weiteren Extensions in Verbindung mit einer Apple Watch Extension. Nach einem Update meiner CocoaPods Installation wurde ich mit folgendem Fehler konfrontiert:
'sharedApplication' is unavailable: not available on iOS (App Extension)
Ich konnte mein Projekt nicht mehr bauen, doch dafür gibt es einen kleinen Kniff, den ich bei Stackoverflow entdeckt habe:
To remove sharedApplication issue from CocoaPods Libraries you just need to change Build Options within Build Settings for your pod.
Just type to search Require Only App-Extension-Safe API and then change the value to NO as it is on the image below:
Propably you will need to do this for every of your pods.
Das hat bei mir jedenfalls geholfen, auch wenn das an sich keine schöne Lösung ist.
Quelle: Link
Mit dem Umstieg von Xcode 6.2 auf Xcode 6.3 werden das aktuelle iOS SDK, sowie weitere Deploymenttools ausgeliefert. Wenn du ein historisch gewachsenes Projekt am Start hast, dann kann es bei dem Umstieg zu verschiedensten Problemen kommen:
Problem 1: Interface Builder Files (xib-Files)
„Could not load NIB in bundle“ war die Fehlermeldung, die ich nach der Umstellung auf Xcode 6.3 erhalten habe. Hat wohl was mit der aktuellen Version der integrierten „ibtool“ Bibliothek zu tun, war in diversen Einträgen zu lesen. Die dort geschilderten Lösungen trugen aber nicht zu Lösung meines Problems bei und waren auch teilweise nicht umsetzbar (da ich Size Classes in meinen XIB-Files verwende).
Abhilfe schaffte bei mi eine Einstellungsmöglichkeit in den betreffenden XIB-Files:
Damit musste ich auch keine Size-Classes deaktivieren und meine App stürzt an den entsprechenden Stellen auch nicht mehr ab.
Anscheinend gibt es auch noch ein Problem mit dem Tildezeichen in der Benamung der xib-Files. Deswegen am besten das Zeichen nicht mehr verwenden und stattdessen das Minus- oder den Unterstrich benutzen (das funktioniert jedenfalls bei mir)
Problem 2: „Embedded binary’s bundle identifier is not prefixed with the parent app’s bundle identifier“
Ich habe in meiner App eine Watch Kit App integriert, sowie unterschiedliche Deployments für Debug und Live. Zu diesem Zweck hatte ich für das Main-Target Custom Variablen angelegt. Bis Xcode 6.2 hat das Bauen auch super funktioniert, da man für die Watch Kit App einfach diese Custom Variable im „Bundle Indentifier“ weglassen konnte. Unter Xcode 6.2 hatte man nämlich keine Möglichkeit sie für das „WatchKit App“-Target über die Projekteinstellung zu setzen. Dies ist ab Xcode 6.3 nun möglich. Dort wurden die Einstellungen eben für dieses Target aufgebohrt und man kann nun Custom Variables eben für diesen Anwendungsfall setzen. Hat man dies getan, können diese Custom Variablen auch zur Generierung des Bundle Indentifiers genutzt werden.
Problem 3: WatchKit Code Signing Issues mit Xcode 6.3
Unter Xcode 6.3 gibt es durch die neuen Einstellungsmöglichkeiten für die WatchKit App nun Code Signing Issues beim Deployen. Possible Mobile beschreibt in einem ausführlichen Beitrag, wie man dieses Problem beheben kann.
Ich stand vor dem Problem die Buildnummern für mein App-Target, sowie der WatchKit Extension und der WatchKit App synchron zu halten. Gelöst habe ich das mittels eines Buildscripts.
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$INFOPLIST_FILE")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$SRCROOT/AppName WatchKit Extension/Info.plist"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$SRCROOT/AppName WatchKit App/Info.plist"Quelle: Stackoverflow
Da ich gerade doch einige Zeit mit Jenkins und Provisioning Profiles verbracht habe, möchte ich euch an dem Lösungsansatz teilhaben lassen.
Gefunden habe ich ihn auf dieser Seite:
Link: Jenkins Guide
Ein paar Punkte, die bei mir essentiell wichtig waren:
Ich habe heute mehrere Minuten mit der Suche nach der Ursache für folgendes Problem verbracht. Damit ihr nicht ewig suchen müsst gibts hier die Lösung gleich parat:
1. Buttontyp in dem Layoutfile von System auf Custom stellen!
2. Folgendes Snippet als Wrapper für euren Code benutzen:
[UIView setAnimationsEnabled:NO];
[_button setTitle:@"title" forState:UIControlStateNormal];
[UIView setAnimationsEnabled:YES];
Weiterführende Infos: Link