"Apple's path with Swift doesn't seem to solve the problems I have as a day-to-day iOS developer. "

That's the key take-away for me.

Of course Swift has an easier time with some syntactic issues than Objective-C, which is two languages crashed into each other. And yes, Objective-C was way, way overdue for a better replacement. Heck, just dropping the "C" part from the language syntax and reducing it to type annotations in a nice typed Smalltalk (see Strongtalk, or TS) would have fit the bill.

It's not as if there aren't lots of problems (and your list will almost certainly be different). For example, applications are no longer just code, non-code resources are just as important, but support for them is at best rudimentary. So with pluggable scheme handlers and polymorphic identifiers, we could write

    checkBoxImage := img:checkbox.

And have the "img" scheme handler statically check resource availability against a list automatically imported from Xcode's resources (pluggable, see F# type providers). Of course, the internet also happened, so

    shoppingPage := http://amazon.com/

should also work, because why should obtaining resources outside your machine have so much extra ceremony. Abstracting should of course also work:

    scheme:amazon := ref:http://amazon.com asScheme
    shoppingPage := amazon:/

And of course you can compose scheme handlers, so you add JSON or XML decoding and then use the resulting scheme handlers as if the original data source

Then there is keeping UI and model in sync. There were bindings, but these were hacky, somewhat unreliably, undebuggable etc. Much better to generalize and integrate a constraint mechanism into the language:

    -<void>setupTemperatureConverter
    {
        ivar:f |= (9.0/5.0) * ivar:c + 32 .
        ivar:c |= (ivar:f - 32) * (5.0/9.0).
        ivar:k |= ivar:c + 273.
        ivar:c |= ivar:k - 273.


        ivar:c =|= ivar:celsiusTextField/intValue.
        ivar:f =|= ivar:fahrenheitTextField/intValue. 
        ivar:k =|= ivar:kelvinTextField/intValue. 
    }

That's actual code for a temperature converter app, setting up relationships that get automatically maintained. And if you make constraint handling support pluggable as you should, you also have a proper syntax for writing autolayout constraints. And Makefiles.

Together with composable scheme handlers (see above), this gets rid of the vast majority of your view controller code.

Then there's the nib vs code dance. Or storyboards. All semi-solutions to problems that are largely (but not entirely) architectural in nature. All can be aided tremendously by good linguistic support, putting to rest many of the recurring problems we have with these technologies (or conversely with not adopting them).

Swift does nothing for any of this.