Environment
OS: OS X Yosemite Version 10.10.3IDE: Xcode Version 6.3.1
Precondition(s)
Project created as Single View Application.
XCode configuration
state is in the default state (same as when initially downloaded).
Problem
This problem is less about source code in that it pertains in part to the IDE tool. XCode offers this feature to design UIs and workflows in an interface builder called Storyboards. Every Storyboard has a scene, and from videos of XCode 5+, it appears you can drag these scenes around to organize them along with the segues. For my IDE instance, I can drag-n-drop scenes from the Object Library into the editor, but once there, I can no longer adjust or move them around. The scenes appear "pinned" to the editor. This results in scenes overlapping one another. Basically, I have a ball of scenes in the middle of my editor currently.
Research Background
I have spent the better part of the day exploring XCode for ways to enable adjustments and/or googling. Googling this issue has not helped as XCode documentation seems to assume this is intuitive and works out-of-the-box (which is how it should be IMO). Results for developers having issues with dragging-n-dropping objects/scenes into the editor seems to be more common so any results for this, if any, gets eclipsed.
Questions
So I have the following questions:
Is there a switch or configuration that I have somehow missed in XCode that essentially "unpins" these scenes from the editor?
Or is it a bug/new feature that has either a workaround/new concept to apply/learn?
Related
I've just cloned a repo from GitHub into my Xcode project and for some reason after a few minutes, my storyboard became incredibly unresponsive and slow.
I am running a MacBook Pro with an i9, 16 GB ram, and the AMD Raedon Pro 5500M (I have tried disabling integrated graphics)
Everything I have seen online tells me to delete xcuserdata and xcshared data but I cannot do this as I am working on a project which uses source control and server-side building and from what I've read doing this breaks the source control.
Here's what I have tried:
Disabling integrated graphics
Re-cloning
Refactoring views into their own storyboard.
Any help is appreciated as I'm very fed up with this.
Unfortunately if you can't get rid of xcuserdata and xcshared you are a bit limited. I would still try and delete them to see if it helps speed up these (you can always revert). If they are to blame at least you know who to blame for your problems.
Other than that I can recommend to look for things that slow down storyboards. Like #IBDesignables which were invented by a demon.
Also, do you have many view controllers in your storyboard. A good practice is to have only one controller per storyboard to limit these side effects. (or none at all if you want to live long and healthy). You can refactor these out of your main storyboard to try and locate what is slowing it down. And additionally refactor custom views out of it into full code classes.
Wish I could be of more help.
1.Check iCloud storage and status if your project in iCloud shared Documents
2.Break the storyboard into small storyboards
3.Remove hardcoded large size image on storyboard
4.Update Xcode
I am new to sketch 3. I have a hand on experience with Xcode and iOS development.
My question is wether we can directly use sketch elements in xcode or sketch is only used for prototyping the UI?
For example, If I design Label with a text field in sketch then can I used it as UI Label and UITextField in Xcode?
In my experience as a designer that also develops in Xcode any solutions that claim to go directly from Sketch into Xcode either become vapourware after some time or don't provide a very good solution. I assume it's because Auto Layout is quite complicated and fragile.
It's best to just learn iOS development using Storyboards or possibly SwiftUI for layout. There are some elements that you can get from Sketch into Xcode such as colors, typography and iconography.
Here's a list of apps that can help you with that:
Zeplin: Handoff designs and styleguides with accurate specs, assets, code snippets automatically. https://zeplin.io
InVision: Prepare designs for development. https://www.invisionapp.com/feature/inspect
Avocado: Open designs without design tools. Export images without preparing layers. Click on layers to get code.
https://avocode.com/hand-off-and-inspect
Flawless: A tool to compare the expected design and the real app right inside iOS Simulator (useful for designers who use Xcode or
mobile developers). https://flawlessapp.io
Sketch to Xcode: The fastest way to get colors from Sketch to Xcode. https://sketchtoxcode.com
Disclaimer: I'm the maker of this app.
There is not a way to integrate the sketch elements in xcode, you can use a sketch plug-in you can buy:
https://www.paintcodeapp.com/sketch
I had the same problem, the design was already prepared in the Sketch and wanted to get the code from it easily. My friends and I've working on a solution for converting design into UI codes, last 2 years.
We've developed Monday Hero platform to improve the development phase and actually save time for repetitive code. https://www.mondayhero.io
In Monday Hero, you can upload design and get responsive code with Storyboard, Xib or only code options. You can also select the elements on the design, group them as you wish for your code library and download it easily in like 15 minutes :) It was a dream of me to get the UI code that easily, I hope it can be also useful to you.
I'm developing a game for iOS 9 in Swift, my testing device is a iPhone 6.
In Xcode I edited a .sks file with the help of the built in Scene Editor (changed the background color, added new nodes etc.). My problem is that these changes are not applied to my compiled game.
I tried following approaches but were not successful:
Clean the project before building it
Run the app on the simulator
Any ideas on what I am doing wrong?
Edit: I discovered that after closing the file through "File->Close" and reopening it the old content appeared again. Can somebody explain me why this was happening? I'm sure I saved the file before and were not editing another file.
SpriteKit and SceneKit Scene Editors are buggy, works in progress.
You'll find all sorts of quirks from one version to another. Unfortunately this might well be one of them. There's no consistency to these quirks and oddities.
There's also no descriptions of changes made from one version of iOS to another with regards Sprite Kit or Scene Kit, which is causing a great deal of annoyance because it's left to the small community to find the changes through trial and error and the sorts of experience you're having.
A compendium of issues would be helpful, and you'd think someone like Apple would have sufficient resources.
If corporations are people, too, then Apple is a poor communicator with attitude issues and a highly secretive nature.
I want to have in my app some nice slide navigationmanu just like in SWRevealViewController. My problem is that SWRevealViewController needs iOS 7.0 and ARC and in my project I have iOS 6.0 without ARC. Is there any way to use SWRevealViewController in my app or maybe there is any alternative to it?
You might want to take a look at ViewDeck https://github.com/Inferis/ViewDeck
It is compatible with iOS 6 and non-ARC.
I cannot tell about SWRevealViewController without ARC or iOS7 (thus I cannot directly answer your question), but I would put a lot of weight behind the following :
Over 80% of all iOS devices currently run iOS7 or greater. ARC has been available since iOS5, which is several years ago.
The mobile market is a quickly evolving one. Not upgrading will quickly lead you to a dark path where you'll end up fighting a losing battle. I understand that your project probably has limitations, but converting right now and keeping up with new technologies will save you a lot of trouble (for instance, trying to make a newer component work with your specific setup).
I would add, the same goes for AutoLayout. If you aren't using it already, you should start, NOW. Rumor has it the next iPhones will vary in size, and the legacy way of handling visuals cannot scale correctly (perhaps the whole reason AutoLayout was created is to prepare this change).
So in short, I wouldn't recommend adapting a new component to your old project, but rather updating your old project to make it modern. You'll end up saving a lot of time.
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.