Easier sharing of structured data between iOS applications and share extensions

Overview

XExtensionItem

Build Status Version Platform License Carthage compatibile

XExtensionItem is a tiny library allowing for easier sharing of structured data between iOS applications and share extensions. It is targeted at developers of both share extensions and apps that display a UIActivityViewController.

We’d love your thoughts on how XExtensionItem could be made more useful. This library’s value comes from how useful it is for apps and extensions of all shapes and sizes.

Why?

Multiple attachments

Currently, iOS has an unfortunate limitation which causes only share extensions that explicitly accept all provided activity item types to show up in a UIActivityViewController. This makes it difficult for an application to share multiple pieces of data without causing extensions that aren’t as flexible with their allowed inputs to not show up at all. Consider the following example:

  • A developer wants their app’s users to be able to share a URL as well as some text to go along with it (perhaps the title of the page, or an excerpt from it). An extension for a read later service (like Instapaper or Pocket) might only save the URL, but one for a social network (like Tumblr or Twitter) could incorporate both.
  • The application displays a UIActivityViewController and puts both an NSURL and NSString in its activity items array.
  • Only extensions that are explicitly defined to accept both URLs and strings will be displayed in the activity controller. To continue the examples from above, Tumblr/Twitter would be displayed in the activity controller but Instapaper/Pocket would not.

Rather than passing in multiple activity items and losing support for inflexible extensions, its best to use a single NSExtensionItem that encapsulates multiple attachments. This can be difficult to get exactly right, however. XExtensionItem makes this easy by providing a layer of abstraction on these complicated APIs, dealing with all of their intricacies so you don’t have to.

Metadata parameters

Being able to pass metadata parameters to a share extension is extremely useful, but the iOS SDK doesn’t currently provide a generic way to do so. Individual developers would need to come up with a contract, such that the extension knows how to deserialize and parse the parameters that the application has passed to it.

XExtensionItem defines this generic contract, allowing application to pass metadata that extensions can easily read, each without worrying about the implementation details on the other end of the handshake. It even provides hooks for extension developers at add support for custom metadata parameters.

Getting started

XExtensionItem is available through your Objective-C package manager of choice:

CocoaPods

Simply add the following to your Podfile:

pod 'XExtensionItem'

Carthage

Simply add the following to your Cartfile:

github "tumblr/XExtensionItem"

Usage

This repository includes a sample project which should help explain how the library is used. It has targets for both a share extension and an application; you can run the former using the latter as the host application and see the data from the application get passed through to the extension.

Applications

You may currently be initializing your UIActivityViewController instances like this:

[[UIActivityViewController alloc] initWithActivityItems:@[URL, string, image] 
                                  applicationActivities:nil];

As outlined above, this is problematic because your users will only be presented with extensions that explicitly accept URLs and strings and images. XExtensionItem provides a better way.

XExtensionItemSource *itemSource = [[XExtensionItemSource alloc] initWithURL:URL];
itemSource.additionalAttachments = @[string, image];

[[UIActivityViewController alloc] initWithActivityItems:@[itemSource] 
                                  applicationActivities:nil];

XExtensionItemSource needs to be initialized with a main attachment (an NSURL in the above example). The main attachment’s type will determine which system activities and extensions are presented to the user. In this case, all extensions and system activities that at least accept URLs will be displayed, but all three attachments will be passed to the one that the user selects.

In addition to a URL, an XExtensionItemSource instance can also be initialized with:

  • An NSString
  • A UIImage
  • NSData along with a type identifier
  • A placeholder item and a block to lazily provide the actual item (once an activity has been chosen)

Advanced attachments

An included XExtensionItemSource category provides additional convenience identifiers for lazily supplying URLs, strings, images, or data:

XExtensionItemSource *itemSource = 
     [[XExtensionItemSource alloc] initWithImageProvider:^UIImage *(NSString *activityType) {
        if (activityType == UIActivityTypePostToTwitter) {
            return twitterImage;
        }
        else {
            return defaultImage;
        }
     }];

Additional attachments can be provided for all activity types:

itemSource.additionalAttachments = @[string, image];

As well as on a per-activity type basis:

[itemSource setAdditionalAttachments:@[tweetLengthString, image] 
                     forActivityType:UIActivityTypePostToTwitter];

In addition to NSURL, NSString, and UIImage, the additional attachments array can also include NSItemProvider instances, which gives applications some more flexibility around lazy item loading. See the NSItemProvider Class Reference for more details.

Generic metadata parameters

In addition to multiple attachments, XExtensionItem also allows applications to pass generic metadata parameters to extensions.

The following parameters are currently supported (more information on each can be found in the XExtensionItemSource header documentation):

  • A title (also used as the subject for system activities such as Mail and Messages)
  • Attributed content text (can also be specified on a per-activity type basis)
  • A thumbnail image
  • Tags
  • A source URL
  • Referrer information
    • App Name
    • App store IDs (iTunes and Google Play)
    • URLs where the content being shared can be linked to on the web, or natively deep-linked on iOS and Android

Some built-in activities (e.g. UIActivityTypePostToTwitter) will consume the attributed content text field (if populated), while others (e.g. “Copy” or “Add to Reading List”) only know how to accept a single attachment. XExtensionItem is smart enough to handle this for you.

If you have an idea for a parameter that would be broadly useful (i.e. not specific to any particular share extension or service), please create an issue or open a pull request.

Custom metadata parameters

Generic parameters are great, as they allow applications and share extensions to interoperate without knowing the specifics about how the other is implemented. But XExtensionItem also makes it trivial for extension developers to add support for custom parameters as well.

Extension developers can create a class that conforms to the XExtensionItemCustomParameters, which application developers will then be able to populate. Here’s a Tumblr-specific example:

XExtensionItemSource *itemSource = [[XExtensionItemSource alloc] initWithURL:URL];
itemSource.additionalAttachments = @[string, image];
itemSource.tags = @[@"lol", @"haha"];

// Provided by Tumblr’s developers. If you’re an extension developer, you can provide your own!
XExtensionItemTumblrParameters *tumblrParameters = 
    [[XExtensionItemTumblrParameters alloc] initWithCustomURLPathComponent:@"best-post-ever"
                                                               consumerKey:nil];

[itemSource addCustomParameters:tumblrParameters];

By default, all custom parameter classes will be included when you pull XExtensionItem into your application. If you want more granular control over what is included, we’ve added support for this in the form of subspecs (CocoaPods) and submodules (Carthage).

If you’re an extension developer and would like to add custom parameters for your extension to XExtensionItem, please see the Custom Parameters Guide.

Have a look at the Apps that use XExtensionItem section for additional documentation on how to integrate with specific extensions.

Extensions

Convert incoming NSExtensionItem instances retrieved from an extension context into XExtensionItem objects:

 for (NSExtensionItem *inputItem in self.extensionContext.inputItems) {
    XExtensionItem *extensionItem = [[XExtensionItem alloc] initWithExtensionItem:inputItem];

    NSString *title = extensionItem.title;
    NSAttributedString *contentText = extensionItem.attributedContentText;

    NSArray *tags = extensionItem.tags;

    NSString *tumblrCustomURLPathComponent = extensionItem.tumblrParameters.customURLPathComponent;
 }

Apps that use XExtensionItem

If you're using XExtensionItem in either your application or extension, create a pull request to add yourself here.

Apps

The following apps use XExtensionItem to pass flexible data to share extensions:

Extensions

The following share extensions use XExtensionItem to parse incoming data:

Contributing

Please see CONTRIBUTING.md for information on how to help out.

Contact

Bryan Irace

Thank you

Many thanks to Ari Weinstein for his contributions towards shaping XExtensionItem’s API, as well as Matt Bischoff, Oisín Prendiville, and Padraig Kennedy for their invaluable feedback.

License

Copyright 2014 Tumblr, Inc.

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Comments
  • XExtensionItemSource API is Too Complicated

    XExtensionItemSource API is Too Complicated

    I'm a little worried that XExtensionItemSource is a little bit confusing/difficult to use for newcomers. Normal users might not be familiar with what a "placeholder item" is or why it's here.

    It seems confusing that you can initialize an XExtensionItemSource with an attachments array or use the registerItemProvidingBlock: method and what the difference is between those things. And how are people supposed to understand how attributedContentText ties into those things? I worry that you have to be an expert in how UIActivityItemSource/NSExtensionItem/NSItemProvider work in order to use this API.

    Compare that to UIActivityViewController, which (in the simple case) is easy as can be - literally just pass it whatever object you want. I wonder if we should be trying to offer a slightly higher-level API that abstracts away a few of these things. Particularly the placeholder item, the attachments array, and the attributedContentText/attributedTitle properties. I think that attributedTitle and subject are fundamentally the same concept and could be easily merged (since the activities that use subject never use attributedTitle)

    Working on ideas for alternatives.

    enhancement 
    opened by AriX 17
  • Should XExtensionItemMutableParameters be replaced with a builder class?

    Should XExtensionItemMutableParameters be replaced with a builder class?

    Mutability should be avoided. A great way to provide an easy-to-use object creation API is by using the builder pattern.

    Unfortunately, many Objective-C developers seem adverse to using builders. As such, the first version of this library includes the XExtensionItemMutableParameters subclass, which allows one to create an XExtensionItemParameters instance without using its initializer (which takes a large number of arguments).

    I'd prefer a builder but want this library to be as approachable as possible. The introduction of a builder class means XExtensionItemMutableParameters would be deleted altogether, and XExtensionItemParameters's large initializer would be made private. The only way to get an instance would be to use the builder object and then call build at the end.

    help wanted question 
    opened by irace 13
  • Rewriting the README

    Rewriting the README

    https://github.com/tumblr/XExtensionItem/issues/32

    Rewriting the README to incorporate all of the API changes. I’d absolutely love your feedback on how we can make this more comprehensive yet as approachable and clear as possible.

    Some links may be broken until the Carthage PR is merged; I’ll handle that once it’s in.

    There’s also a link to a wiki page which I’ve yet to write. This’ll happen tomorrow.

    @arix @mattbischoff @prendio2 @padraigk

    opened by irace 11
  • Add hooks for providing alternative items, subjects, and thumbnail images

    Add hooks for providing alternative items, subjects, and thumbnail images

    Adds hooks for providing alternative items, subjects, and thumbnail images on a per-activity type basis. Addresses the following tickets:

    • https://github.com/tumblr/XExtensionItem/issues/33
    • https://github.com/tumblr/XExtensionItem/issues/35

    I’m going to punt on updating the README for now since I want to do a bigger pass at rewriting it for 1.0.

    Other requests which have been broken out into separate issues:

    • https://github.com/tumblr/XExtensionItem/issues/40
    • https://github.com/tumblr/XExtensionItem/issues/41
    enhancement 
    opened by irace 10
  • Add a framework target (and as such, Carthage support)

    Add a framework target (and as such, Carthage support)

    https://github.com/tumblr/XExtensionItem/issues/42

    Diverge from the traditional pod lib create project structure in order to add first class framework support.

    • XExtensionItem.xcodeproj in the root directory now has a framework target and the tests target.
    • Example/XExtensionItemExample.xcworkspace contains a sample application and share extension, and pulls XExtensionItem in as a development pod

    Also fixes a bug in XExtensionItem.m and updates the unit tests such that they will fail if it returns.

    To test

    • Verify that the framework target builds without any warnings or errors, and that tests all pass
    • Verify that the sample application and share extension function as expected
    • Verify that a sample project is able to consume XExtensionItem via Carthage
    opened by irace 7
  • Add the ability to provide alternative items on a per-activity type basis

    Add the ability to provide alternative items on a per-activity type basis

    Provide hooks for giving specific items to specific activities, instead of simply passing the same fully-populated NSExtensionItem everywhere (e.g. to send different representations to Twitter, Facebook, Mail.app, etc.)

    I can think of three different ways to register alternative items off the top of my head (these methods would all be on XExtensionItemSource:

    @implementation XExtensionItemSource
    
    ...
    
    // Simplest – just provide a value that should be used in place of the default `NSExtensionItem` if a specific activity is picked
    - (void)registerItem:(id)item forActivityType:(NSString *)activityType;
    
    // More complex – provide a block that returns a value, to avoid necessarily creating values for activities that may never be selected
    - (void)registerItemProvider:(void (^)())itemProvider forActivityType:(NSString *)activityType;
    
    // Most flexible – provide an object that determines what item should be returned for an activity type
    
    @property (nonatomic) id <XExtensionItemProvider> alternativeItemProvider;
    
    @end
    
    @protocol XExtensionItemProvider
    
    - (id)itemForActivityType:(NSString *)activityType;
    
    @end
    

    Usage would look something like:

    [itemSource registerItem:twitterLengthSummaryString forActivityType: UIActivityTypePostToTwitter];
    
    [itemSource registerItemProvider:^{
        // Lazily compute the Twitter-specific summary
        return twitterLengthSummaryString;
    } forActivityType: UIActivityTypePostToTwitter];
    
    @implementation MyAppCustomActivityItemProvider <XExtensionItemProvider>
    
    - (id)itemForActivityType:(NSString *)activityType {
        if (activityType == UIActivityTypePostToTwitter) {
            return self.twitterLengthSummaryString;
        }
    
        // Returning `nil` would mean the activity/extension gets the default `NSItemProvider` instead of something special
        return nil;
    }
    
    @end
    
    itemSource.alternativeItemProvider = [[MyAppCustomActivityItemProvider alloc] init];
    

    I feel like @arix will have opinions on this one.

    enhancement 
    opened by irace 7
  • Exclusively use inferred type identifiers

    Exclusively use inferred type identifiers

    Related: https://github.com/tumblr/XExtensionItem/issues/49

    We should be able to lazily provide items that don’t match the placeholder’s type, in order to e.g. provide a GIF if the message activity is selected. This requires using our function to calculate the item’s type rather than the type identifier that was provided when the item source was initialized.

    The only other place where self.typeIdentifier was being used was in the UIActivityItemSource protocol’s activityViewController:dataTypeIdentifierForActivityType: method, but that seemed to be causing a problem due to the mismatch. I’ve removed it and everything seems to work fine.

    Totally possible that I’m overlooking something here – please take a look through and let me know if you think this is necessary for some reason.

    enhancement 
    opened by irace 6
  • Add additional parameters to `XExtensionItemSourceApplication`

    Add additional parameters to `XExtensionItemSourceApplication`

    Talk with @chrismaddern to make sure we’re on the same page with regards to which parameters apps should use to attribute themselves.

    Here’s what we have so far: https://github.com/tumblr/XExtensionItem/blob/master/XExtensionItem/XExtensionItemSourceApplication.h

    enhancement help wanted question 
    opened by irace 6
  • Allow a default `subject` to be provided

    Allow a default `subject` to be provided

    As per @prendio – allow a default subject to be provided rather than explicitly registering subjects for individual activity types using the registerSubject:forActivityType: method added in this pull request.

    (This isn’t particularly pressing since there isn’t public API for extensions to read this value, and only Mail and Messages support subjects out of the built-in activities (which only change once a year, at most), but we only just realized that the latter does yesterday, so who knows what else we could potentially be missing?)

    A couple of options:

    • Use the attributedTitle value if it exists and a subject was not explicitly registered for a given activity type
    • Add a @property (nonatomic, copy) NSString *defaultSubject; property
    • Document that calling registerSubject:forActivityType: with a nil activity type will register it as the default. I think I like this one the best.

    Thoughts?

    enhancement 
    opened by irace 4
  • Don’t pass extension items to system activities that can’t consume them

    Don’t pass extension items to system activities that can’t consume them

    :rage::rage::rage::rage::rage::rage::rage::rage::rage::rage::rage:

    Thanks to @prendio2 for catching this one. While some system activities do know how to consume NSExtensionItem input, others like Mail and Messages do not. Passing an NSExtensionItem to these doesn’t result in any data making its way through.

    Unfortunately I don’t know a better way to handle this other than to deduce (via trial and error) which activities can support extension item input, and pass the placeholder object to the ones that can’t.

    This PR to add more UIActivityItemSource hooks makes these changes a lot easier to swallow, in my opinion, even though this still sucks. I definitely need to radar this.

    CC: @mattbischoff @arix

    bug 
    opened by irace 4
  • Project structure should match what `pod lib create` generates

    Project structure should match what `pod lib create` generates

    Is two Xcode projects confusing? @twigz seems to think so. The arguments I can remember him making:

    1. It’s not the default from pod lib create
    2. If you’re working on the library in the normal code → test your code in the sample app workflow, it’s more difficult to run the unit tests.
    enhancement non-functional 
    opened by mattbischoff 4
  • iOS 9

    iOS 9

    :warning: Preliminary thoughts! Please take this with a grain of salt as I haven’t thought about it for long enough to feel like I have my head fully wrapped around it. :warning:

    To try and determine what modifications we may want/need to make to XExtensionItem in the short term, I think it’s worthwhile to consider how we’d want the library to function if we only needed to support iOS 9.

    XExtensionItem for iOS 8 has two goals:

    • Support multiple attachments (obviated by iOS 9)
    • Support metadata parameters (still useful on iOS 9)

    Therefore, XExtensionItem usage on iOS 9 only could look something like the following:

    // Application
    
    // `XExtensionItem` no longer wraps your attachments, instead it’s just an additional metadata object
    [[UIActivityViewController alloc] initWithActivityItems:
     @[@"Apple homepage", [NSURL URLWithString:@"http://apple.com"], xExtensionItemSource] 
                                      applicationActivities:nil]
    
    // Extension
    
    // Rather than treat *every* item as something that can be wrapped by an `XExtensionItem`, just specifically look to see if one was passed in
    for (NSExtensionItem *item in self.extensionContext.inputItems) {
        if ([XExtensionItem isXExtensionItem:item]) {
            XExtensionItem *xExtensionItem = [[XExtensionItem alloc] initWithExtensionItem:item];
            // Access tags, app attribution, custom application parameters, etc.
        }
        else {
            // Process regular, non-XExtensionItem item
        }
    }
    

    Ideally, we’d release what we currently have (let’s call it 1.0) and add a section to the README documenting how we envision the library changing in order to eventually better support iOS 9 exclusively. Then at some point we cut a new release for developers who only support 9 (let’s call this 2.0), and those who continue to support 8 can just use the older version.

    But the problem here is interoperability. An application that uses XExtensionItem 1.0 (e.g. provides a single XExtensionItem instance as their lone activity item) wouldn’t be compatible with an extension that uses 2.0 (I need to think about it a little more but I think an app that uses 2.0 will still work just fine with an extension that uses 1.0).

    How can we resolve this? It seems as though modifying the extension-facing API to support both types of input is the most future-proof course of action. Otherwise, we’d have to either:

    • Go iOS 9 only and not be useful to anyone who needs to support iOS 8 for a while still (bad option, almost no one will use this)
    • Forget about changing the library in the future to better mesh with how activity items work in a post-iOS 9 world (makes this library very useful in the short term but more annoying to use than it needs to be post-iOS 9)

    @mattbischoff @prendio2 @AriX

    help wanted question 
    opened by irace 2
  • Should be able to specify titles on a per-activity type basis

    Should be able to specify titles on a per-activity type basis

    The more I think about this, the more I think we would actually want to be able to key titles off of activity types, if we’re going to use them as the subject that the UIActivityItemSource provides. I realized this by sharing from the Tumblr app to the Tumblr extension and realizing that our subjects written specifically for email don’t translate well to quote posts or link posts, where we consume the title field in our extension.

    enhancement 
    opened by irace 0
  • There isn’t currently a way to lazily return (typed) `NSData` from a provider block

    There isn’t currently a way to lazily return (typed) `NSData` from a provider block

    You can return an NSData instance but there’s no way to specify a type identifier that differs from the one that the XExtensionItemSource was initialized with.

    bug 
    opened by irace 0
  • Consider supporting iOS 7

    Consider supporting iOS 7

    It would just pass a single item through rather than providing any of the benefits, but at least would make it easier for apps that still support iOS 7 to simply drop XExtensionItem in.

    enhancement 
    opened by irace 6
  • Add pod lib linting back to `.travis.yml` once a CocoaPods supports JSON spec linting

    Add pod lib linting back to `.travis.yml` once a CocoaPods supports JSON spec linting

    Add this back to the .travis.yml file:

    - pod lib lint --quick
    

    Once this command actually looks for JSON podspecs (https://github.com/CocoaPods/CocoaPods/issues/3477)

    enhancement non-functional 
    opened by irace 0
Releases(0.9.4)
  • 0.2.0(May 4, 2015)

    • Broke XExtensionItemParameters out into two separate classes: XExtensionItemSource as application output and XExtensionItem as share extension input
      • Removed mapping of type identifiers to representations now that we can pass multiple attachments through
      • Removed imageURL property now that we can pass multiple attachments through
    • Added custom Tumblr parameter support
    • Removed Core Location dependency
    • Re-worked project structure to be consistent with pod lib create
    • Renamed XExtensionItemSourceApplication to XExtensionItemReferrer
    • Added more referral parameters
    Source code(tar.gz)
    Source code(zip)
Owner
Tumblr
Tumblr
Message passing between iOS apps and extensions.

MMWormhole MMWormhole creates a bridge between an iOS or OS X extension and its containing application. The wormhole is meant to be used to pass data

Mutual Mobile 3.9k Dec 28, 2022
A way to represent what you’re sharing.

About This project provides a preview of items being shared via UIActivityViewController. Example: // standard activity view controller let vc = UIAct

Ryan Ackermann 759 Nov 24, 2022
A NEWS app which can be used to read,share and bookmark articles of various categories

Scoop A NEWS App for iOS 14 built using Swift which allow the users to read,bookmark and share news articles. Built using MVC architecture Requirement

Sai Balaji 3 Oct 12, 2022
swift-highlight a pure-Swift data structure library designed for server applications that need to store a lot of styled text

swift-highlight is a pure-Swift data structure library designed for server applications that need to store a lot of styled text. The Highlight module is memory-efficient and uses slab allocations and small-string optimizations to pack large amounts of styled text into a small amount of memory, while still supporting efficient traversal through the Sequence protocol.

kelvin 4 Aug 14, 2022
An open source Instapaper clone that features apps and extensions that use native UI Components for Mac and iOS.

TODO: Screenshot outdated Hipstapaper - iOS and Mac Reading List App A macOS, iOS, and iPadOS app written 100% in SwiftUI. Hipstapaper is an app that

Jeffrey Bergier 51 Nov 15, 2022
Enzyme is a spm package for the make easier development on iOS

Enzyme Enzyme is a spm package for the make easier development on iOS. Installation For the installation you just need to add the url of the project t

Ebubekir 2 Jan 20, 2022
Useful Swift code samples, extensions, functionalities and scripts to cherry-pick and use in your projects

SwiftyPick ?? ?? Useful Swift code samples, extensions, functionalities and scripts to cherry-pick and use in your projects. Purpose The idea behind t

Manu Herrera 19 May 12, 2022
SharkUtils is a collection of Swift extensions, handy methods and syntactical sugar that we use within our iOS projects at Gymshark.

SharkUtils is a collection of Swift extensions, handy methods and syntactical sugar that we use within our iOS projects at Gymshark.

Gymshark 1 Jul 6, 2021
A Collection of useful Swift property wrappers to make coding easier

Swift Property Wrappers A Collection of useful Swift property wrappers to make c

Gordan Glavaš 2 Jan 28, 2022
BFKit-Swift is a collection of useful classes, structs and extensions to develop Apps faster.

Features • Classes and Extensions Compatibility • Requirements • Communication • Contributing • Installing and Usage • Documentation • Changelog • Exa

Fabrizio Brancati 992 Dec 2, 2022
A Swift package for rapid development using a collection of micro utility extensions for Standard Library, Foundation, and other native frameworks.

ZamzamKit ZamzamKit is a Swift package for rapid development using a collection of micro utility extensions for Standard Library, Foundation, and othe

Zamzam Inc. 261 Dec 15, 2022
Steps and files needed to reproduce a CSP bug in Safari Web Extensions

CSP Safari bug repro There appears to be a discrepancy between how Safari handles CSP policies for extension pages compared to how other browsers do s

Brian Birtles 0 Nov 6, 2021
Extensions for Swift Standard Types and Classes

Cent Cent is a library that extends certain Swift object types using the extension feature and gives its two cents to Swift language. Dollar is a Swif

Ankur Patel 225 Dec 7, 2022
Useful functions and extensions for sorting in Swift

SwiftSortUtils Motivation This library takes a shot at making comparing and sorting in Swift more pleasant. It also allows you to reuse your old NSSor

Daniel Strittmatter 60 Sep 9, 2022
Collection of native Swift extensions to boost your development. Support tvOS and watchOS.

SparrowKit Collection of native Swift extensions to boost your development. Support iOS, tvOS and watchOS. If you like the project, don't forget to pu

Ivan Vorobei 119 Dec 20, 2022
A μframework of extensions for SequenceType in Swift 2.0, inspired by Python's itertools, Haskell's standard library, and other things.

SwiftSequence Full reference here. (If you're looking for data structures in Swift, those have been moved to here) SwiftSequence is a lightweight fram

Donnacha Oisín Kidney 376 Oct 12, 2022
Helpful extensions for iOS app development 🚀

ExtensionKit includes many extensions, from getting the user location with a deterministic Combine API to a shimmer loading animation, to keyboard notification updates, bottom sheet and much much more. Check out the docs below or install the library with SPM to try it out.

Gary Tokman 110 Oct 31, 2022
Personally useful Swift Extensions for iOS Development

Useful-Swift-Extensions Personally useful Swift Extensions for iOS Development; cobbled together from a variety of development projects and StackOverf

Nick Arner 5 Dec 13, 2021
Common iOS extensions

NVExtensions Common iOS extensions. Requirement iOS 13.0+ Swift 5.5+ Dependencies SwiftDate Installation Swift Package Manager The Swift Package Manag

Vinh Nguyen 1 Feb 27, 2022