I am wondering if it is possible (and if so, some elaboration and steps to achieve) building out a custom iMessage
Extension WITHOUT using storyboards? I have my core app, and then have the additional iMessage extension target. My main app is working fine without storyboards.
I followed the tutorial here, however it is not working and makes the original app look really funky upon deleting the Launch screen interface file base name info.plist entry from the main app. This tutorial is from 2016 and uses Objective C, so that might also have something to do with it.
I know that the launch screen for the main app now requires a storyboard, and everything is working fine there.
One way is to do it in SwiftUI.
Here's a link to another question that has a complete example of a bug, but to your question has a stub of a message extension that displays a very simple view. You could expand on that.
imessage extension app group conversation send fails on first run
Related
I'd like my app to appear in the list of suggested applications that can be seen after taking a screenshot in iOS.
For example, currently when a user takes a screenshot and taps the send/export button, a modal appears over the bottom half of the screen which contains a list of applications that the user can export the image to, and even a more button which contains further app options.
What needs to be done in swift iOS app project (using xcode ide) in order to achieve this?
To display your app in theUIActivityViewController, you need to create a Share Extension for your application. To create a share extension for your project, go to file > new > target > Share Extension. You can refer to Apple's Documentation for share extension!
I am working on a project. Project has a lot of ViewContrllers. And taking a lot of space in phone. I wonder if there is any way to make ViewContrllers loading as packages.
For example user selects main menu, main menu and 3 another ViewContrllers associated with it will be downloaded and as soon as the user quits the app they can be erased from the phone.
I know it causes a lot of data usage. But i just wonder is it possible to upload your ViewContrllers on cloud and download them in app when using and remove them after using.
Some ideas:
You could use some kind of React Native, or equivalent, solution.
You could define your View Controllers as JSON and configure a specialised UIViewController with this JSON.
Those ideas aside, I don't think view controllers as XIBS, Storyboard, or in code, should be detrimental to the size of the app.
I have a basic understanding of how to make iOS apps with Swift in Xcode Projects (I can make apps like flappy birds and an adapted variation of pong). My main target for this year is to be able to at least apply for the Apple WWDC student scholarship. I have read online that the scholarship submission needs to be completed and uploaded in Swift playgrounds.
As I am self-taught, I have little to no experience with Swift playgrounds. So my main question is: how do I make an application in playgrounds? I am used to beginning with a main.storyboard, but I can't find that in Swift playgrounds.
How do you go about creating an interactive application in Swift playgrounds?
You cannot use storyboards directly in a playground, which is why Xcode doesn't support creating a storyboard inside of a playground. You can access a framework from a storyboard inside of a workspace (including cocoapods), so one solution is to make a framework to load your storyboards. This doesn't seem to fit with your criteria of making everything in playgrounds though. So you can either make all of your view programmatically or you can drag in compiled nib files to your Playground Resources folder and load the nibs from there (the playground cannot load xib, which is the XML representation of the nib).
When I click new file and go to user interface tab, I don't see the application or window options. The application file description should say "An Interface Builder document suitable for creating an iOS application, including an application delegate and window." I tried searching in the search bar in Xcode but application did not show up for iOS.
Please see screen shots and difference for clarity.
app delegate screenshot 2
my screen
Apple introduced storyboards back in 2011. Before that, developers used a .xib file to specify their user interfaces, and the "main" .xib file, i.e. the first one that the app loaded, included a proxy for the app delegate so that it was easy to connect objects to outlets in the app delegate. As matt has indicated, though, things haven't really worked that way for a while. As he says, it sounds like you're working from an old book or online tutorial, and as a result your expectations don't match the reality of modern iOS development.
These days, apps generally use a storyboard to specify all or part of the user interface. A big problem with .xib files was that you had to load an entire file at once; if you instantiated a view controller with -initWithNibName:bundle:, the entire file was loaded. That meant that you could only specify a single view controller in a given .xib file, and managing the relationships between view controllers was harder than it should be. Storyboards address this problem -- a single storyboard typically contains several view controllers.
I agree with matt that you really shouldn't work from material so old that it expects you to use .xib files to build your application. That story again:
STOP USING THAT INFORMATION
There are plenty of great resources (notably matt's own iOS 9 Programming Fundamentals with Swift) that will teach you how to write modern iOS code. Apple's own documentation is a great place to start.
I want to design my own custom input view keyboard using a custom keyboard extension in swift. The existing Xcode 6.1 default set of keyboards do not fit my app needs. What I want is an enhanced number pad which I would modify, like in the Soulver app in the iOS app store. http://www.acqualia.com/soulver/iphone/
Ultimately I do not need a custom keyboard extension to offer to other apps but I do not mind if my app offers one. It looks to me like custom keyboards are the right place to start for for a custom input view keyboard.
I finally just about have digested constraints in the editor and would like to make use of a storyboard or xib.
I do need to be able to programmatically select the keyboard extension within the app.
The keyboard/custom view needs to be available to the app that contains it without activation in iOS settings.
Can this be done as an extension given the requirements, or can the custom keyboard extension be easily converted to a custom input view? Can you illustrate either one or point out sample Swift code I missed when searching? Thank you.
I am writing a keyboard extension in Swift right now and highly recommend not doing the same. Both Swift and the Keyboard Extension API are brand new, not well documented, creating significant learning curves, and both have significant bugs or weird implementation details to work around.
From the way you phrased your question it doesn't sound like you are very experienced in iOS development, and attempting to learn too many things at once is a recipe for disaster. If I could do my current project over, I would have done it in Objective C just to vastly simplify what I was learning.
But the good news is that you don't need the keyboard to run in other apps. This is good news because writing a custom input keyboard class within your own app is very simple and easy, and a great place to start. There is a good deal of existing documentation on how to do so, including this excellent post on stack overflow.
How do I retrieve keystrokes from a custom keyboard on an iOS app?
More detail:
The standard custom input view API in cocoa is very powerful, the one in the keyboard extension is almost entirely neutered, so you can do far more with a custom input view than you can with a keyboard Extension. To activate a keyboard extension requires getting the user to turn it on in their iPhone settings, there is no way around that and no way to pick which keyboard they choose within your app (other than to not allow custom keyboard extensions at all).
If you need to access the internet or data within your app for any reason (tracking usage information, activating an in-app purchase, accessing preferences) you must also convince your user to turn on "Full Access", which presents an incredibly scary alert that reads to users as if turning it on means you will be able to spy on them and steal their passwords
Getting back to why you don't want to use Swift in an extension. First, Objective C doesn't cause Xcode's code parser to crash many times a day, while developing in Swift does, sometimes crashing Xcode itself. In Objective C the debugger is almost always correct, in the current version of Swift often you can't see array or dictionary contents, sometimes what it shows is inaccurate, and when stepping through code often takes nonsensical routes. Developing in Objective Code means you won't have to update your code because of changes to Objective C itself, with Swift it's pretty much guaranteed they'll make significant syntax changes every major release (the last one in September did).
Developing a keyboard extension means sometimes your extension won't load for mysterious reasons, and you'll need to waste hours debugging why. My Swift keyboard extension is sometimes debugged solely with println() statements because I can't get the debugger to load. Since Apple's tools don't yet work well with Keyboard extensions, and also don't yet work well with Swift, using them together are multiplying your pain exponentially.
The end result is if you don't need to use this keyboard outside of your own application it's foolish to build it using the Keyboard extension API. If you do need to use the Keyboard extension API it's foolish to do it in Swift. This is written by a fool working full time trying to ship a Swift based keyboard extension.
If you want to use the standard cocoa custom input view API, then using Swift is probably fine. You will still have to deal with additional problems because it's such a young language, but you won't have lose so many days to mysterious, seemingly insoluble problems trying to figure out if they were caused by Swift, the Keyboard Extension API, failures in Xcode and it's debugger, or your own blunder.