ERROR : perhaps the designated entry point is not set? - ios

Hello EveryOne I am following THIS awesome tutorial but I didn't download stater project because I want to create a different app I have done everything where I want to pop up only CenterViewController with Left side ViewController Both are in ContainerViewController But I got This in my Console:
2014-11-19 14:04:46.838 SlideTable[3612:87749] Failed to instantiate the default view controller for UIMainStoryboardFile 'Main' - perhaps the designated entry point is not set?
I also tried THIS answer but got same result.
What this error means I have done all the required things as the auther provided at start up project but I didnt found any solution for this.
This is the code for may project.
AppDelegate.swift
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
window = UIWindow(frame: UIScreen.mainScreen().bounds)
let containerViewController = ContainerViewController()
window!.rootViewController = containerViewController
window!.makeKeyAndVisible()
return true
}
Am I missing something?
I will provide further information if needed.

I have met the same issue and I found the solution:
Select the Main.storyboard;
Open Attributes inspector and click Is Initial View Controller in the View Controller section.
This operation works well for me according to the same error message.

The main controller of you app (the entry point), does it have the the "Is Initial View Controller" checked on the right bar? It will show an arrow next to it.

Update for Xcode 11, and iOS 13.
In addition to elia's answer, you have to change one more attribute in Info.plist file.
In Info.plist file it is needed to change String value for Storyboard Name to the name of your initial file that you want to first appear during launching of the application.
By default value for Storyboard Name is set to "Main", and you need to change it.
You can find that attribute in:
Info.plist -> Application Scene Manifest -> Scene Configuration -> Application Session Role -> Item 0 -> Storyboard Name

I solved this problem by clicking on
Product -> Clean Build Folder

When you use more than one UIStoryboard and want to init your UIViewController except the Main.storyboard for example Intro.storyboard, then you would probably get this error. You must select
YourProject -> TARGETS -> Deployment Info -> Main Interface
In Main Interface, there are several UIStoryboard that you created for your own project. Choose the right one which contains your UIViewController.
I mean
YourProject -> TARGETS -> General -> Deployment Info -> Main Interface.
Not YourProject -> TARGETS -> Deployment Info -> Main Interface.

There exists a compatibility issue between IOS 12 and IOS 13.
So you have to remove the Application Scene Manifest from the info.plist in order for it to function correctly. Also, you have to remove everything related to scenes from the App Delegate.

Related

Xcode 11 Could not find a storyboard named 'Main' in bundle NSBundle

This question has been asked before, but my issue is specifically with Xcode 11 and UISceneConfiguration. Before Xcode 11, when you deleted a storyboard (Main.storyboard) from your target, then added a new one (AnotherStoryboard.storyboard), you would have to update Targets > General > Deployment Info > Main Interface to use your newly added storyboard. In Xcode 11, this is not sufficient and the app will throw an exception
*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
reason: 'Could not find a storyboard named 'Main' in bundle NSBundle
The problem I found was that in Info.plist, there is now a new key titled UIApplicationSceneManifest that has a nested UISceneStoryboardFile in it that is being updated when you change the Main Interface within the target. However, there is still a UIMainStoryboardFile key at the top level of Info.plist that is holding the title of the old "Main" storyboard. Long story short, if you delete UIMainStoryboardFile, the app will run fine.
My question: Is this a bug in Xcode 11 or is there something else I'm missing that would prevent this? I didn't really find anything useful while I was trying to debug it and ended up figuring it out on my own.
In your info.plist Main file is set in Scene Configuration, So it always find that file and throw an exception. You can set your default ViewController programatically. In your info.plist set Scene Configuration to Default configuration and Select none into Targets > General > Deployment Info > Main Interface.
Your sceneWillConnectTo be like
window = UIWindow(frame: UIScreen.main.bounds)
window!.windowScene = windowScene
window!.rootViewController = //your homeVC
window!.makeKeyAndVisible()
In your info.plist you have to set this property
Application Scene Manifest -> Scene Configuration -> Application Session Role -> Item 0 -> Storyboard Name
Info.plist

Xcode: Different targets have different rootViewController?

I've got an app that's functional (in the app store). In the past, we only had one version of our app with one Target in Xcode. Our development cycle is getting a little more complex, so we want to have two Xcode targets: production and development. These two targets would have two different bundle identifiers so we can have the different versions running on the phone at the same time. This is a similar strategy to this: https://www.raywenderlich.com/68613/create-paid-lite-version-iphone-app
I've basically followed the raywenderlich instructions to duplicate my target and set a preprocessor macro. The only change so far is using a different icon.
The "Original" version of the app is the "production" version. The newly duplicated target is the "development" version.
I'm using a storyboard where the LaunchViewController is set as the Is Initial View Controller option.
In the AppDelegate, I have code that gets the root viewcontroller via window?.visibleViewController and sets some information on it:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]? = nil) -> Bool {
// ...
guard let launchVC = window?.visibleViewController as? LaunchViewController else {
NSLog("visibleViewController is nil or not LaunchViewController")
return
}
NSLog("calling startUserManagerAndLogin - launch")
launchVC.startUserManagerAndLogin()
// ...
return true
}
In the original (production) version of the app, everything continues to work fine. I see the following line in the console, and the app launches correctly:
... Visible View Controller: Optional(<MyApp.LaunchViewController: 0x7f84dea02a00>)
However in the development version of the app. I'm seeing the guard case fail. Here's what I see in the console:
... Visible View Controller: Optional(<UIViewController: 0x7fbd1e509570>)
... visibleViewController is nil or not LaunchViewController
The root view controller is different between the production and development targets. I don't see how the root view controller can be different between two targets unless I explicitly set that (which I didn't).
I checked the project files and the "General -> Deployment Info" is the same between the two targets. I also checked the storyboard, and there's nothing there that specifies different view controllers.
Any ideas what's going on or how I can fix it?
Thanks!
Gah! FFS I figured it out. Turns out there was another log line that I missed that said:
... Unknown class _TtC8MyApp20LaunchViewController in Interface Builder file.
I found this out because I tried instantiating my LaunchViewController by hand (from the storyboard) and got this error as well. I figured out that the module was wrong.
I then found the SO question: XCODE 7.1 Swift 2 Unknown class in Interface Builder file which helped me find that there were some old storyboard elements that didn't have Inherit Module From Target selected. I toggled the checkbox to on, and now it's working. Phew.

Cannot resolve identifier from Cocoapod Xcode 7.2.1 Swift 2.2

I've been following this tutorial religiously which is verified for Swift 2.0 and Xcode 7.1 (as per the title I'm using Xcode 7.2.1 Swift 2.2), so I get stuck on the article "Using Your New CocoaPod" where you've implement it. I followed it along precisely, and my app delegate look like this:
import UIKit
import RWPickFlavor
#UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
var window: UIWindow?
var rootViewController: UIViewController!
func application(application: UIApplication, didFinishLaunchingWithOptions
launchOptions: [NSObject : AnyObject]?) -> Bool {
setupRootViewController()
window = UIWindow(frame: UIScreen.mainScreen().bounds)
window?.rootViewController = rootViewController
window?.makeKeyAndVisible()
return true
}
func setupRootViewController() {
let bundle = NSBundle(forClass: PickFlavorViewController.self)
let storyboard = UIStoryboard(name: "Main", bundle: bundle)
rootViewController = storyboard.instantiateInitialViewController()!
}
}
but I have an error on the following line:
let bundle = NSBundle(forClass: PickFlavorViewController.self)
The error message reads: "Use of unresolved identifier 'PickFlavorViewController'"
Has something happened in between swift 2.0 and 2.2 affecting the CocoaPods and how can I resolve it?
It looks like you didn't copy the PickFlavorViewController into your project, which is mentioned in your tutorial:
Now drag and drop everything — except for AppDelegate.swift and LaunchScreen.xib — from the above groups in IceCreamShop.xcworkspace into the corresponding groups in RWPickFlavor.xcworkspace like this:
Copy the controller and all should be fine. Good luck!
The Beginner's guide to Making your CocoaPods
The issue I had here, despite following the tutorial to the spot was that when I copied the files over, they were moved into the root folder of my Swift cocoa pod project folder in my filesystem. This is why I go the error message that my class couldn't be found.
NOTE!
Just because you made a group in your xcode project it does not mean that Xcode will make any kind of folder architecture in regards to that.
Xcode's project structure is a pointer-based system that points to a file no matter where it is in your computer's file system. Moving it in Xcode does not move it in the folder!
In my case the files were copied into the root folder and per default the pod with look into the folder named like your project that's located in the root folder, but it won't see what's in your root and therefor not find the files when you use the pod.
How do I fix it?
In your root folder (the one where you can find the RWPickFlavor.xcworkspace) of your pod project you have a folder with the same name as your project. Move all your swift files into that folder.
Update your pod to accomondate your changes:
git add .
git commit -m 'Refactored the files (Or whichever commit message you want here)'
git tag 0.2.0
git push origin master --tags
pod repo push RWPodSpec RWPickFlavor.podspec
And in your Ice Cream Shop project root (Once again, where you find the [ProjectName].xcworkspace) run a pod install with your updated pod.
Some of these pod steps may be unnecessary, but this is what I did to solve my problem.

How can I set flags that my app will see when it's running under XCTest?

KIF works like magic, something puzzled me a lot recently. That is how exactly KIF and XCTest works.
It is said in WWDC 2014 & 2013: Test code is injected into the host application as kind of a plugin, so what information can be eavesdrop from main app as a plugin? What is the relationship between Host Application & Plugin??
Using KIF, we can sense the Notifications & URL request, but how that works? My first thought is all context in host application is shared with plugin But why in test, we cannot modify variables in the main app?
For example:
we have two targets:
Magic Project
-- MagicApp
-- MagicUITest <- KIFTest target
Suppose I have a file called MagicClass:
class MagicClass {
static var a = 1
}
Is that possible if I want to modify that variable in MagicUITest?
The problem I faced right now is how can I inject different UIViewController to RootViewController so that I can run KIF test from each individual ViewController and don't need bother going through the login process all the time .. my guess is something like:
in MagicApp:
class AppDelegate : .. , .. {
func application(application: UIApplication, willFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]?) -> Bool {
if MagicClass.a == 1 {
window.rootViewController = AViewController()
} else {
window.rootViewController = BViewController()
}
}
}
in KIFTest's setUp() :
setUp() {
Magic.a = 2
}
But not work ..
One thing is Magic.a = 2 won't change the Magic.a in MagicApp, second is application(..,..,..) function will end before setUp() is called ..
Any idea ?
While you're correct that the exact code you've tried won't work, you'll be able to use a very similar approach.
This code, for example, is cribbed directly from the app I'm working on right now in a class called RootViewController that's (you guessed it) the app's root view controller:
public override func viewDidAppear(animated: Bool) {
super.viewDidAppear(animated)
if NSProcessInfo.processInfo().environment["TESTING"] == nil {
loadChildren()
}
}
What it does is looks for an environment variable to decide if it should automatically continue with loading the app, and if it finds the environment variable it waits for the test stack to finish setting up and telling it what portion of the app to load next. (You could do this in your app delegate, too, if it's a really small app.)
You can set the environment variable by editing the scheme in Xcode:
All that said, though: take care when using this strategy. You want your tests to be testing features of your app as they exist in your app, and if showing different screens arbitrarily is a feature of your app, that's probably okay. But if you start writing code that makes your app behave differently when under test, you're not really testing your app anymore, are you?

dyld_fatal_error with Typhoon+Swift+iOS7.x+Plist-bootstrapping

I have very annoying problem with Typhoon Framework version 2.3.0 in Swift project.
I included Typhoon in Podfile as mentiond in tutorial, installed Pods, created bridging header and added #import <Typhoon/Typhoon.h> in this header.
Then I created assembly subclass called ApplicationAssebly :
import Foundation
public class ApplicationAssembly: TyphoonAssembly {
public dynamic func appDelegate() -> AnyObject {
return TyphoonDefinition.withClass(AppDelegate.self) {
(definition) in
definition.injectProperty("myAssembly", with: self)
}
}
}
As you see I want to inject that assembly into AppDelegate.
I have also added TyphoonInitialAssemblies entry in Info.plist file. And in this moment my problems has started. I have tested few combinations resulting in NSException :
Can't resolve assembly for name xxx
This combinations are (typhtest is project/bundle name):
ClassName in Info.plist: ApplicationAssembly, Defines Module property in Build Settings : No
ClassName in Info.plist: ApplicationAssembly, Defines Module property in Build Settings : Yes
ClassName in Info.plist: typhtest.ApplicationAssembly, Defines Module property in Build Settings : No
ClassName in Info.plist: typhtest.ApplicationAssembly, Defines Module property in Build Settings : Yes
I have found this answer on StackOverflow so I've tried the last combination :
ClassName in Info.plist: _TtC8typhtest19ApplicationAssembly, Defines Module property in Build Settings : Yes
This combination doesn't throw NSException but I have dyld_fatal_error, stack trace from iPhone 5s (iOS 7.1) below :
I get slightly different stack trace from iPhone simulator (iOS 7.1) :
What is strange that it works on iOS 8.1 simulator ! Also Typhoon Sample Application for Swift works well on my device.
I also tried to clean any Xcode and project caches and DerivedData directories, I've cleaned project and build folder and rebuilded the project, but it's not working. My Xcode version is 6.1 (6A1052d) and I'm using OSX Yosemite 10.10.1 .
GitHub repository with my code : https://github.com/papcio28/Typhoon-Dyld-Error
Edited 21.11.2014
What is also strange is that if I create the factory manually and inject something also manually, Typhoon works. Steps that I've made are :
Removed TyphoonInitialAssemblies item from Info.plist
Changes AppDelegate.application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool to
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
let factory = TyphoonBlockComponentFactory(assemblies: [AppAssembly()])
factory.inject(self)
return true
}
But it doesn't change a fact that I want to use Typhoon without defining factory manually, so the question is still actual.
This issue has been reproduced as a bug and will be resolved ASAP. It was also reproduced in the Typhoon sample app, after pod update, meanwhile a clean checkout works fine. This would suggest that a regression bug has crept in somewhere between 2.2.1 and 2.3.0, however checking this yielded some strange results, so it might not actually be the case. We'll post updates/discoveries to the issue log.
Workaround:
In the meantime, please bootstrap Typhoon by overriding the following method in your AppDelegate:
dynamic func initialFactory() -> TyphoonComponentFactory {
return TyphoonBlockComponentFactory(assemblies:[
ApplicationAssembly(),
AnotherAssemblyIfRequired()])
}
This approach bootstraps Typhoon just like plist-integration, and so provides UIStoryboard integration, UIStateRestoration and so forth. . it was not documented until now, as we thought thought the plist style of staring Typhoon was sufficient and it would be simply confusing to provide too many options. However in this case it works for iOS7.1+Swift+Storyboards while plist does not.
Namespacing:
As for the namespace issue, it should not be necessary to mangle the name in the plist file as you did - Typhoon will detect if implicit namespaces are available and handle this transparently. But, if this is not working currently in iOS7.x, you can add a directive to your assembly as follows:
#objc(ApplicationAssembly)
public class ApplicationAssembly : TyphoonAssembly {
//etc
}
Edit: Fixed in Typhoon 2.3.1:
As of Typhoon 2.3.1, plist bootstrapping can now be used with Swift+iOS7.x

Resources