column

You probably want to do this:Change the display name of your existing app (see the note)Create your second app with the old display name (adding the info.plist)You cannot change the bundle id but there is no need to do so, just update the display nameTechnical Q&A QA1823Updating the Display Name of Your AppQ: How do I change the name displayed underneath my app icon on my device's Home screen?A: To change the name appearing underneath your app icon, modify the CFBundleDisplayName key in your Info.plist. Follow these steps to modify CFBundleDisplayName:In Xcode, click the disclosure triangle next to your app folder in the project navigator to reveal its content as shown in Figure 1.Click the disclosure triangle next to the Supporting Files subfolder to reveal its content.Select the Info.plist file to reveal a property list editor of keys and values.By default, Xcode displays a human-readable string of a key rather than its actual name. So, search the property list for Bundle display name. Skip to step 5 if

I may be reading your code wrong but, it seems kind of redundant to repeat thereturn { row, column inlet newCol = -2 * columnAlso, it seems to me you only need the default:return (newCol, 0) once for instance in the final else clause.

Again, I may be reading your code incorrect but something like:private func generateLoserLocationFunction(numberOfPlayers: Int) -> (column: Int, row: Int) -> (column: Int, row: Int) {return { row, column inlet newCol = -2 * columnswitch numberOfPlayers {case 8:switch column {case 0:return (newCol, row / 2)case 1:return (newCol, row ^ 1)}case 16:switch column {case 0:return (newCol, row / 2)case 1:return (newCol, 3 - row)case 2:return (newCol, row ^ 1)}case 32:switch column {case 0:return (newCol, row / 2)case 1:return (newCol, (row + 4) % 8)case 2:return (newCol, row)case 3:return (newCol, row ^ 1)}default:return (newCol,0)}}It's not a big change, 35 lines instead of 50 but if I'm reading it right, it should do the same thing your existing versiondoes.

Although not understand the purpose of your code (which makes it difficult to propose any improvement), try this:private func generateLoserLocationFunction(numberOfPlayers: Int) -> (column: Int, row: Int) -> (column: Int, row: Int) { switch numberOfPlayers { case 8,16,32: return { row, column in let newCol = -2 * column switch column { case 0: return (newCol, row / 2) case 1 where numberOfPlayers == 8: return (newCol, row ^ 1) case 1 where numberOfPlayers == 16: return (newCol, 3 - row) case 1 where numberOfPlayers == 32: return (newCol, (row + 4) % 8) case 2 where numberOfPlayers == 16: return (newCol, row ^ 1) case 2 where numberOfPlayers == 32: return (newCol, row) case 3 where numberOfPlayers == 32: return (newCol, row ^ 1) default: return (newCol, 0) } } default:abort() } }You also can combo some cases like this:case 1,2 where numberOfPlayers < 32: return (newCol, row ^ 1)But only you can tell whats make sense for your code.

I'm sorry, maybe I'm being totally dense, but what Wallace wrote would be no different than if I had just done this and not returned a new function:func theMethodToCallOverAndOver(column: Int, row: Int) -> (column: Int, row: Int) { let newCol = -2 * column switch column { case 0: return (newCol, row / 2) case 1 where numberOfPlayers == 8: return (newCol, row ^ 1) case 1 where numberOfPlayers == 16: return (newCol, 3 - row) case 1 where numberOfPlayers == 32: return (newCol, (row + 4) % 8) case 2 where numberOfPlayers == 16: return (newCol, row ^ 1) case 2 where numberOfPlayers == 32: return (newCol, row) case 3: return (newCol, row ^ 1) default: return (newCol, 0) } }That means every time I call the method, I'm checking the value of numberOfPlayers.

This is the best I can come up with:private func generateLoserLocationFunction(numberOfPlayers: Int) -> (column: Int, row: Int) -> (column: Int, row: Int) { let closure : (column: Int, row: Int) -> (Int) if numberOfPlayers == 8 { closure = { row, column in switch column { case 0: return row / 2 case 1: return row ^ 1 default: return 0 } } } else if numberOfPlayers == 16 { closure = { row, column in switch column { case 0: return row / 2 case 1: return 3 - row case 2: return row ^ 1 default: return 0 } } } else if numberOfPlayers == 32 { closure = { row, column in switch column { case 0: return row / 2 case 1: return (row + 4) % 8 case 2: return row case 3: return row ^ 1 default: return 0 } } } else { abort() } return { row, column in let newCol = -2 * column return (newCol, closure(column: row, row: column)) } }

Oh, ok. I had misunderstood what you are trying to accomplish.FWIW, besides the fact there is not what you want, maybe i should have written in this way...private func generateLoserLocationFunction(numberOfPlayers: Int) -> (column: Int, row: Int) -> (column: Int, row: Int) { switch numberOfPlayers { case 8,16,32: return { row, column in let newCol = -2 * column switch (column,numberOfPlayers) { case (0,_): return (newCol, row / 2) case (1,8), (2,16), (3,32): return (newCol, row ^ 1) case (1,16): return (newCol, 3 - row) case (1,32): return (newCol, (row + 4) % 8) case (2,32): return (newCol, row) default: return (newCol, 0) } } default:abort() } }But going back to you problem, so, if i understand well, it's a case of premature optimization, like in our example of colors:func generateGetColorFunction(numberOfPlayers: Int) -> () -> UIColor { if numberOfPlayers == 8 { return { return UIColor.redColor() } } else if numberOfPlayers == 16 { return { return UI

Not only does this seem like premature optimization, but I suspect that it's actively counterproductive.When you structure the code using a function-returning function, you're preventing the compiler from doing any inlining. The compiler can't assume that theMethodToUse points anywhere in particular, because its value is calculated at run-time. So any reference to theMethodToUse() will probably result in an actual function call. I suspect you'd be better off from a performance standpoint doing an inlined switch on the number of players, even if that value is constant.But you really can't say for sure without doing some testing. And regardless of the answer, this code is highly unlikely to ever be a performance bottleneck. You just shouldn't be worrying about performance in this context until you've been able to prove that it's an issue in the environment of the completed application.As far as brevity, I don't think you can do much better than Wallacy's revised version with the tuple-valued switch. But that co

After viewing the video sessions from 2012 to 2015 from WWDC, I was able to figure out how to set up a table cell and and group text labels into one phrase.However, I am disappointed in the current support provided for the UIPicker. This just isn't acceptable. The accessibility API needs to be expanded for elementsthat take input so that the user has a better experience. Specifically, it would be nice to have an API that summarizes the UIPicker and helps to describe how many columns have been placed side by side. If multiple columns are being used (ie, a date picker), it would also be nice if the user received the changing values periodically and cohesively across the columns.I am also very disappointed with the accessibility API for the UITextField. More API is needed to guide the user to understand the usage of things like customized keyboards and scrolling to edit multiple textfields. When a textfield is used in an alertViewController, the voice over message is incoherent as it bounces fr