erichoracek/EHObjectSyncManager 13
Leverages RestKit to observe managed object changes and automatically and transparently communicates them to a server.
erichoracek/ELCImagePickerController 7
A clone of the UIImagePickerController using the Assets Library Framework allowing for multiple asset selection
An iOS app for scanning/OCR license plates and posting emoji reactions to them, built in a day as part of an Automatic hackday
erichoracek/feedbackreporter 3
Framework for sending feedback and system information reports from you Cocoa application.
erichoracek/MGImageUtilities 3
Useful UIImage categories for iPhone/iPad developers.
erichoracek/CarthageStaticSwiftTest 2
An example of a Carthage project using static Swift frameworks
Fetches YouTube mp4 URLS for iOS
RestKit is a framework for consuming and modeling RESTful web resources on iOS and OS X
erichoracek/EHObjectSyncManager-Rails-Example 1
EHObjectSyncManager Rails Example
startednatanrolnik/Glider
started time in 3 days
Pull request review commentairbnb/swift
Place a MARK comment before types and extensions
_You can enable the following settings in Xcode by running [this script](resourc * <a id='newline-at-eof'></a>(<a href='#newline-at-eof'>link</a>) **Files should end in a newline.** [](https://github.com/realm/SwiftLint/blob/master/Rules.md#trailing-newline) +* <a id='mark-types-and-extensions'></a>(<a href='#mark-types-and-extensions'>link</a>) **Each type and extension should be preceded by a `MARK` comment.** [](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#markTypes)+ * Types should be preceded by a `// MARK: - TypeName` comment.+ * Extensions that add a conformance should be preceded by a `// MARK: TypeName + ProtocolName` comment.+ * Extensions that follow the type being extended should omit that type's name and instead use `// MARK: ProtocolName`.+ * If there is only one type or extension in a file, the `MARK` comment can be omitted.+ * For extensions that do not add new conformances, consider adding a `// MARK:` with a descriptive comment.++ <details>++ ```swift+ // MARK: - GalaxyView++ final class GalaxyView: UIView { }++ // MARK: ContentConfigurableView++ extension GalaxyView: ContentConfigurableView { }++ // MARK: Galaxy + SpaceThing++ extension Galaxy: SpaceThing { }
I can see the argument for the plus—sounds good to me.
comment created time in 7 days
Pull request review commentairbnb/swift
Place a MARK comment before types and extensions
_You can enable the following settings in Xcode by running [this script](resourc * <a id='newline-at-eof'></a>(<a href='#newline-at-eof'>link</a>) **Files should end in a newline.** [](https://github.com/realm/SwiftLint/blob/master/Rules.md#trailing-newline) +* <a id='mark-types-and-extensions'></a>(<a href='#mark-types-and-extensions'>link</a>) **Each type and extension should be preceded by a `MARK` comment.** [](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#markTypes)+ * Types should be preceded by a `// MARK: - TypeName` comment.+ * Extensions that add a conformance should be preceded by a `// MARK: TypeName + ProtocolName` comment.+ * Extensions that follow the type being extended should omit that type's name and instead use `// MARK: ProtocolName`.+ * If there is only one type or extension in a file, the `MARK` comment can be omitted.+ * For extensions that do not add new conformances, consider adding a `// MARK:` with a descriptive comment.++ <details>++ ```swift+ // MARK: - GalaxyView++ final class GalaxyView: UIView { }++ // MARK: ContentConfigurableView++ extension GalaxyView: ContentConfigurableView { }++ // MARK: Galaxy + SpaceThing++ extension Galaxy: SpaceThing { }
If we're adding commas between protocols it feels like we should just have the mark contents match the Swift declaration since folks are familiar with that syntax, e.g. Galaxy: SpaceThing, DarkMatterContaining. Using a plus feels less precise, especially since we're only using it for protocol conformances and not other types of marks
comment created time in 12 days
Pull request review commentairbnb/swift
Place a MARK comment before types and extensions
_You can enable the following settings in Xcode by running [this script](resourc * <a id='newline-at-eof'></a>(<a href='#newline-at-eof'>link</a>) **Files should end in a newline.** [](https://github.com/realm/SwiftLint/blob/master/Rules.md#trailing-newline) +* <a id='mark-types-and-extensions'></a>(<a href='#mark-types-and-extensions'>link</a>) **Each type and extension should be preceded by a `MARK` comment.** [](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#markTypes)+ * Types should be preceded by a `// MARK: - TypeName` comment.+ * Extensions that add a conformance should be preceded by a `// MARK: TypeName + ProtocolName` comment.+ * Extensions that follow the type being extended should omit that type's name and instead use `// MARK: ProtocolName`.+ * If there is only one type or extension in a file, the `MARK` comment can be omitted.+ * For extensions that do not add new conformances, consider adding a `// MARK:` with a descriptive comment.++ <details>++ ```swift+ // MARK: - GalaxyView++ final class GalaxyView: UIView { }++ // MARK: ContentConfigurableView++ extension GalaxyView: ContentConfigurableView { }++ // MARK: Galaxy + SpaceThing++ extension Galaxy: SpaceThing { }
extension Galaxy: SpaceThing { … }
comment created time in 12 days
Pull request review commentairbnb/swift
Place a MARK comment before types and extensions
_You can enable the following settings in Xcode by running [this script](resourc * <a id='newline-at-eof'></a>(<a href='#newline-at-eof'>link</a>) **Files should end in a newline.** [](https://github.com/realm/SwiftLint/blob/master/Rules.md#trailing-newline) +* <a id='mark-types-and-extensions'></a>(<a href='#mark-types-and-extensions'>link</a>) **Each type and extension should be preceded by a `MARK` comment.** [](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#markTypes)+ * Types should be preceded by a `// MARK: - TypeName` comment.+ * Extensions that add a conformance should be preceded by a `// MARK: TypeName + ProtocolName` comment.
Shouldn't this also have a dash since it's a standalone type and it should have its own section?
* Extensions that add a conformance should be preceded by a `// MARK: - TypeName + ProtocolName` comment.
comment created time in 12 days
Pull request review commentairbnb/swift
Place a MARK comment before types and extensions
_You can enable the following settings in Xcode by running [this script](resourc * <a id='newline-at-eof'></a>(<a href='#newline-at-eof'>link</a>) **Files should end in a newline.** [](https://github.com/realm/SwiftLint/blob/master/Rules.md#trailing-newline) +* <a id='mark-types-and-extensions'></a>(<a href='#mark-types-and-extensions'>link</a>) **Each type and extension should be preceded by a `MARK` comment.** [](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#markTypes)+ * Types should be preceded by a `// MARK: - TypeName` comment.+ * Extensions that add a conformance should be preceded by a `// MARK: TypeName + ProtocolName` comment.+ * Extensions that follow the type being extended should omit that type's name and instead use `// MARK: ProtocolName`.+ * If there is only one type or extension in a file, the `MARK` comment can be omitted.+ * For extensions that do not add new conformances, consider adding a `// MARK:` with a descriptive comment.++ <details>++ ```swift+ // MARK: - GalaxyView++ final class GalaxyView: UIView { }++ // MARK: ContentConfigurableView++ extension GalaxyView: ContentConfigurableView { }++ // MARK: Galaxy + SpaceThing
Same as above—shouldn't this get a dash since this is the beginning of a new type grouping?
// MARK: - Galaxy + SpaceThing
comment created time in 12 days
Pull request review commentairbnb/swift
Place a MARK comment before types and extensions
_You can enable the following settings in Xcode by running [this script](resourc * <a id='newline-at-eof'></a>(<a href='#newline-at-eof'>link</a>) **Files should end in a newline.** [](https://github.com/realm/SwiftLint/blob/master/Rules.md#trailing-newline) +* <a id='mark-types-and-extensions'></a>(<a href='#mark-types-and-extensions'>link</a>) **Each type and extension should be preceded by a `MARK` comment.** [](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#markTypes)+ * Types should be preceded by a `// MARK: - TypeName` comment.+ * Extensions that add a conformance should be preceded by a `// MARK: TypeName + ProtocolName` comment.+ * Extensions that follow the type being extended should omit that type's name and instead use `// MARK: ProtocolName`.+ * If there is only one type or extension in a file, the `MARK` comment can be omitted.+ * For extensions that do not add new conformances, consider adding a `// MARK:` with a descriptive comment.++ <details>++ ```swift+ // MARK: - GalaxyView++ final class GalaxyView: UIView { }++ // MARK: ContentConfigurableView++ extension GalaxyView: ContentConfigurableView { }
extension GalaxyView: ContentConfigurableView { … }
comment created time in 12 days
Pull request review commentairbnb/swift
Place a MARK comment before types and extensions
_You can enable the following settings in Xcode by running [this script](resourc * <a id='newline-at-eof'></a>(<a href='#newline-at-eof'>link</a>) **Files should end in a newline.** [](https://github.com/realm/SwiftLint/blob/master/Rules.md#trailing-newline) +* <a id='mark-types-and-extensions'></a>(<a href='#mark-types-and-extensions'>link</a>) **Each type and extension should be preceded by a `MARK` comment.** [](https://github.com/nicklockwood/SwiftFormat/blob/master/Rules.md#markTypes)+ * Types should be preceded by a `// MARK: - TypeName` comment.+ * Extensions that add a conformance should be preceded by a `// MARK: TypeName + ProtocolName` comment.+ * Extensions that follow the type being extended should omit that type's name and instead use `// MARK: ProtocolName`.+ * If there is only one type or extension in a file, the `MARK` comment can be omitted.+ * For extensions that do not add new conformances, consider adding a `// MARK:` with a descriptive comment.++ <details>++ ```swift+ // MARK: - GalaxyView++ final class GalaxyView: UIView { }
nit: Include an ellipsis here and below to indicate that this declaration would have content that's been omitted for brevity
final class GalaxyView: UIView { … }
comment created time in 12 days
push eventairbnb/lottie-ios
commit sha bef013d9c414e092714db007fc3dbd4947a9bc55
Switch to Kite animation for example
push time in 14 days
create barnchairbnb/lottie-ios
branch : eh--core-animation-vs-lottie-example
created branch time in 20 days
startedKhan/SwiftTweaks
started time in a month
issue openedKaneCheshire/ShowTime
Feature Request: Automatic mode
It would be awesome if there was a mode that automatically enabled ShowTime if there was an external screen connected or a screen recording started. It seems like you could do this via observing the following Notifications:
UIScreen.didConnectNotification
UIScreen.capturedDidChangeNotification
created time in a month
startedmicrosoft/scalar
started time in a month
startedmicrosoft/VFSForGit
started time in a month
Pull request review commentairbnb/swift
Reintroduce old file organization rules
_You can enable the following settings in Xcode by running [this script](resourc * `// MARK: Fileprivate` for `fileprivate` properties and methods. * `// MARK: Private` for `private` properties and methods. * If the type in question is an enum, its cases should go above the first `// MARK:`.- * If there are typealiases, they should go above the first `// MARK:`.+ * If there are typealiases or nested types, they should go above the first `// MARK:`.
How does this handle types that have a specific access control level? I'd be concerned if nested private types were grouped with public types
comment created time in 2 months
startedSwiftWebUI/AvocadoToast
started time in 2 months
startedswiftwasm/carton
started time in 2 months
startedswiftwasm/JavaScriptKit
started time in 2 months
startedMaxDesiatov/Runtime
started time in 2 months
startedobjective-see/ProcInfo
started time in 2 months
startedobjective-see/ProcInfoExample
started time in 2 months
startedthii/xcbeautify
started time in 2 months
startedKaneCheshire/ShowTime
started time in 3 months
starteddehesa/Conbini
started time in 3 months