Building Apps In Swift With Storyboards

Nerval's Lobster writes Apple touts the Swift programming language as easy to use, thanks in large part to features such as Interface Builder, a visual designer provided in Xcode that allows a developer to visually design storyboards. In theory, this simplifies the process of designing both screens and the connections between screens, as it needs no code and offers an easy-to-read visual map of an app's navigation. But is Swift really so easy (or at least as easy as anything else in a developer's workflow)? This new walkthrough of Interface Builder (via Dice) shows that it's indeed simple to build an app with these custom tools... so long as the app itself is simple. Development novices who were hoping that Apple had created a way to build complex apps with a limited amount of actual coding might have to spend a bit more time learning the basics before embarking on the big project of their dreams.

Comments

Swift is MIA in TFA

[OzPeter]

Where in TFA is Swift actually used? All I see is a simple Interface Builder example which has nothing do with Swift.

Are we going to be continually with crappy iOS articles repeating the basics of UI development just because they have the word "Swift" in them or that they are Dice based??

And another crappy article .. with Swift

Crappy articles are crappy articles and articles like these are the reason that Netcraft confirms that /. is dying.

Re:Swift is MIA in TFA

[tbuddy]

This is the first Dice article I've seen linked and it did not disappoint when it came to disappointing. I think anyone who has looked at Mac OS X from even the most casual development end or UI customizing end already knows at least a little Interface Builder. I was using it in the first four releases of OS X to fix poorly designed interfaces just because as a graphic artist things like that drive you crazy and it is just as easy to edit the nibs than to explain to the devs.

You are absolutely right. This has nothing to do with programming and very little to do with Interface Builder.

Apple's own docs are way better a starting point than this cringeworthy shameless Dice promotion with third rate screen shots. They could have at least had someone with a bit of experience make the screens so it didn't look like it was done by someone who hasn't ever used the application.

Re:Swift is MIA in TFA

[jandrese]

Hypercard is owned by a third party now, and they do offer phone targets for the stacks.

It's kind of a shame. Hypercard was incredibly close to being a modern web browser before web browsers were invented. All it needed was a way to remotely load pages from a stack over your Appletalk network. Javascript might never have been born since HyperTalk would already be doing the job. People would eventually have to address the grave security concerns, but in the early 90s nobody gave a crap about security on home networks. Of course being a Mac only product would also put a serious crimp in widespread adoption (especially since this is the era where Jobs is at Pixar and NeXT so Apple is floundering badly).

I WANT

[bondsbw]

I want to be able to code this to make a game:

int main(int argc, const char* argv[])
{
        CreateGameThatIsSortOfLikeAngryBirdsAndMakeMeMillionsOfDollarsOvernight();
}

Anything else is too hard.

Re:I WANT

[Anonymous Coward]

int main(int argc, const char* argv[])
{
        CreateGameThatIsSortOfLikeAngryBirdsAndMakeMeMillionsOfDollarsOvernight();
        return 0;
}

FTFY

Limited coding isn't everyone's goal

[TechyImmigrant]

Building complex apps without coding doesn't seem like a useful goal. At some point you have to express the program logic and coding has always proven to be the best way.

The dividing line between graphical tool and actual code seems to have been a shifting one over the years. So when you go to a new environment or language where there's a substantial GUI component to building an app, the desire to see it all in code is strong. What actually happens when you add that button? I expect to be able to do it either through code of GUI and if they can't tell me what the GUI did in code, then I'm left clueless as to the underpinnings and so it becomes hard to think through the implications of design decisions.

I tried Swift recently. Swift was easy enough. But Swift+Xcode was impenetrable.

Re:Limited coding isn't everyone's goal

[Maxwell]

Building complex apps without coding doesn't seem like a useful goal. At some point you have to express the program logic and coding has always proven to be the best way.

The dividing line between graphical tool and actual code seems to have been a shifting one over the years. So when you go to a new environment or language where there's a substantial GUI component to building an app, the desire to see it all in code is strong. What actually happens when you add that button? I expect to be able to do it either through code of GUI and if they can't tell me what the GUI did in code, then I'm left clueless as to the underpinnings and so it becomes hard to think through the implications of design decisions.

I tried Swift recently. Swift was easy enough. But Swift+Xcode was impenetrable.

My micro processor prof insisted that C was an abomination and that code was easier to follow in native assembly. (Mostly Motorola, some TI)

There is a big chunk of people who have no desire to see the assembler, or the massively abstract C++ code that created it. Anyone who uses Access for example. I had a tool Palm Toolbox that made simple apps for PalmOS way back when. It was limiting, because I know better, but you could do a lot without ever looking at the real code.

Be prepared for multiple variations of the Fart Machine!

The complexity has to go somewhere

[jandrese]

The dream of some fancy tool that builds a complex app for you (since you're an "ideas person", not a programmer) is always going to be a fantasy. The more work a tool does for you, the more specialized it has to be because there is only so much complexity a person can put into a project per hour they work on it. Either you supply that complexity, or the tool builder does, and there's an upper limit to how complex a tool can be before learning it harder than just learning a programming language and solving the problem yourself.

Someone has to do the work, and if you have grand visions the work will be hard.

Re:The complexity has to go somewhere

[jandrese]

And 30 years? AIs that can think through solutions and look for problems like that are very hard to make, especially in the general case. A lot of AI these days is still little more than massaged Google searches.

Re:The complexity has to go somewhere

[blue9steel]

The dream of some fancy tool that builds a complex app for you (since you're an "ideas person", not a programmer) is always going to be a fantasy.

Always is a long time. Try these statements on for size as a comparison:

"I also lay aside all ideas of any new works or engines of war, the invention of which long-ago reached its limit, and in which I see no hope for further improvement..." - Sextus Julius Frontinus 84 C.E.

"What can be more palpably absurd than the prospect held out of locomotives traveling twice as fast as stagecoaches?" - The Quarterly Review 1825

"The abolishment of pain in surgery is a chimera. It is absurd to go on seeking it... Knife and pain are two words in surgery that must forever be associated in the consciousness of the patient." - Dr. Alfred Velpeau 1839

"Heavier-than-air flying machines are impossible." -Lord Kelvin 1895

"There is not the slightest indication that nuclear energy will ever be obtainable. It would mean that the atom would have to be shattered at will." - Albert Einstein, 1932.

Consider if you will:

An assembler is a way of automatically creating machine code

A compiler is a way of automatically creating assembly code

A ______ is a way of automatically creating program code

Is there some reason we shouldn't expect the blank to be filled in and efforts to move up the stack yet again? As computers become more powerful we can afford ever more complex layers of abstraction.

Re:You say storyboards, I say flowcharts

[preaction]

I'm wondering if those flowcharts actually do help people learn basic program flow and basic boolean logic. After a while, you don't need them, because you can think like the machine. But, for getting started, it might be a good step and encourage thought before shotgun coding.

They are right to say storyboard ...

[perpenso]

"Storyboards" are Apple's name for a user interface layout tool, its not a logic flow tool so it is not really like flowcharts. A storyboard is basically a view pane where you layout the visual elements and controls, and define some constraints involved in repositioning and resizing for different resolutions. There is very limited flow control. Things like clicking on this button brings up a different storyboard.

In short storyboards let you mock up a user interface, including one view launching a different view. If you are nostalgic for the 90s think back to Microsoft's Visual Studio GUI layout and glue code generation tools. Its pretty much the same sort of stuff.

Flowcharts are documentation ...

[perpenso]

Flowcharts are documentation. And they can be pretty concise and more importantly visual.

The visualization aspect is sometimes important. It can literally be the big picture that helps one understand a process. Also visualization can help with debugging something missing at the design level.

Now I haven't used my plastic templates or some software package to generate flowcharts since undergrad days decades ago, but I still on occasion grab a yellow pad of paper and a pencil to informally (ok that was generous, crudely would be more accurate) sketch out some algorithm, data flow, logic, etc. To me its helpful when thinking about some things, planning some things, etc.

Re:You say storyboards, I say flowcharts

[__aaclcg7560]

I haven't done formal flowcharts in ages, but I probably have the plastic template from college stashed in a storage box somewhere. If I'm having trouble with a piece of code, I might make a diagram to visually walkthrough the code and figure out where I'm getting stuck.

Re:You say storyboards, I say flowcharts

[BasilBrush]

What flowcharts encourage is programming with gotos. They became outdated back in the days when structured programming came in. JSP became the thing. Then later various object diagrams being more or less standardised as UML.

The first job interview I had back in 1984 they asked me to draw a flowchart for a certain algorithm. I told them they were outdated and gave them a JSP diagram instead. And I got the job as a result. That's how out of data flowcharts are.

NOT like Microsoft's Visual Studio GUI layout and

[EMB Numbers]

Interface Builder has not changed in any fundamental ways since it debuted in 1988 with NeXTstep.
Unlike crappy Microsoft tools for the 90's, it is NOT a screen drawing tool. It is an object instantiation and configuration tool. You set the properties and relationships between live objects graphically. The objects are then archived (serialized) and later unarchived (deserialized) into your running iOS app.

Watch this from 1992 http://www.youtube.com/watch?v...
Steve Jobs demonstrates Interface Builder starting 23 minutes into the video. Also note that Windows 3.1 shipped in 1992.

Just for fun, here is NeXTstep from 1988 http://www.youtube.com/watch?v...