You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's say sou are working on an iOS app and want to add MKMapView to the project, and you haven't linked the framework or did anything to start working with MapKit API.
the plugin loads all the framework headers associated to the target plus those that are not associated like MapKit.framework
the plugin colors these headers in slightly different color.
on selecting #import <MapKit/MapKit.h> the user is prompted with a list of targets to link MapKit.framework to
the import is added as usual, and MapKit.framework is linked to selected targets
The text was updated successfully, but these errors were encountered:
Yeah that is also in the roadmap, maybe a quicker solution as well...
My idea was that I didn't want to force people to use modules if they don't want to, I think a better approach would be to check if modules are enabled for the project and then do the logic based on that. Does that make sense?
Completely - I actually only noticed this issue as I came to request the @import feature. I would say module support would initially be more important, as any project created in the last year or so should support them. Also they should be much easier to implement.
But you are right that you shouldn't force people to use them if they have a legacy project. It'd probably be worth doing a straw poll with other devs to see what the effective base of developers not using modules is.
Let's say sou are working on an iOS app and want to add
MKMapView
to the project, and you haven't linked the framework or did anything to start working withMapKit
API.MapKit.framework
#import <MapKit/MapKit.h>
the user is prompted with a list of targets to linkMapKit.framework
toMapKit.framework
is linked to selected targetsThe text was updated successfully, but these errors were encountered: