profile
viewpoint
Eric Horacek erichoracek @airbnb San Francisco erichoracek.com iOS & design systems @airbnb

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

erichoracek/Fender 5

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

erichoracek/HCYoutubeParser 2

Fetches YouTube mp4 URLS for iOS

devontivona/RestKit 1

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.** [![SwiftLint: trailing_newline](https://img.shields.io/badge/SwiftLint-trailing__newline-007A87.svg)](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.** [![SwiftFormat: markTypes](https://img.shields.io/badge/SwiftFormat-markTypes-008489.svg)](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.

calda

comment created time in 7 days

PullRequestReviewEvent

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.** [![SwiftLint: trailing_newline](https://img.shields.io/badge/SwiftLint-trailing__newline-007A87.svg)](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.** [![SwiftFormat: markTypes](https://img.shields.io/badge/SwiftFormat-markTypes-008489.svg)](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

calda

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.** [![SwiftLint: trailing_newline](https://img.shields.io/badge/SwiftLint-trailing__newline-007A87.svg)](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.** [![SwiftFormat: markTypes](https://img.shields.io/badge/SwiftFormat-markTypes-008489.svg)](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 { … }
calda

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.** [![SwiftLint: trailing_newline](https://img.shields.io/badge/SwiftLint-trailing__newline-007A87.svg)](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.** [![SwiftFormat: markTypes](https://img.shields.io/badge/SwiftFormat-markTypes-008489.svg)](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.
calda

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.** [![SwiftLint: trailing_newline](https://img.shields.io/badge/SwiftLint-trailing__newline-007A87.svg)](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.** [![SwiftFormat: markTypes](https://img.shields.io/badge/SwiftFormat-markTypes-008489.svg)](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
calda

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.** [![SwiftLint: trailing_newline](https://img.shields.io/badge/SwiftLint-trailing__newline-007A87.svg)](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.** [![SwiftFormat: markTypes](https://img.shields.io/badge/SwiftFormat-markTypes-008489.svg)](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 { … }
calda

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.** [![SwiftLint: trailing_newline](https://img.shields.io/badge/SwiftLint-trailing__newline-007A87.svg)](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.** [![SwiftFormat: markTypes](https://img.shields.io/badge/SwiftFormat-markTypes-008489.svg)](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 { … }
calda

comment created time in 12 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventairbnb/lottie-ios

Eric Horacek

commit sha bef013d9c414e092714db007fc3dbd4947a9bc55

Switch to Kite animation for example

view details

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

calda

comment created time in 2 months

PullRequestReviewEvent

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

more