@hyperoslo/ios We still have a lot of not-released Swift libraries. I think it's time to add some good README, cover image and release them before we merge swift-3 branches to master.

• Aftermath - Vadym
• Imaginary
• Lightbox
• Tabby - Ramon
• AftermathSpots - Vadym
• AftermathCompass - Vadym
• AftermathTools - Vadym
• OhMyAuth - Vadym
• Keychain
• Offline - Vadym
• Dropdown
• Flasker
• Gallery

I think it's a good idea to integrate Danger in our internal and open source projects. Or at least it's worth trying to see how it works for us.

Another no brainer. I like Tailor.

With reusability being in it's DNA, I think this is a contender to be a part of Foundation because of the flexibility that it provides on so many levels. Being able to construct views directly from JSON is great for prototyping and playing around with the look and feel of the application together with designers.

Having a declarative UI that can be served from the backend also shines a bright light on where we could be heading in the future in terms of rapid future development.

It can also easily be conventionalised with the help of other open source like AftermathCompass and AftermathSpots.

I think we're not only discussing about swift libraries, but other tools and services we use as well. That can be analytics, AB testing, deployment service, ...It would be great if we agree on the services that we already use and love.

This is about crash reporting service, and the vote is Fabric Crashlytics

So far, I'm the only one that has used Wrap in a project but I find it's magic simply mind blowing.
Super easy to use and those exactly what you set out to do; I think this can be very useful when storing objects in Cache.

https://github.com/johnsundell/Wrap

The idea behind this issue is to create a dictionary of all iOS projects. There we can add a description of the project, some screenshots and what components that it uses. It can be good to have when doing estimations, to check what we have done in the past but also work as a source of inspiration for upcoming projects. If we already have something similar in an already existing project then it is probably good to re-use it in some way, shape or form.

As Ramon stated in the team meeting (27/9), this is a good time to start making conventions for how we move forward with iOS, and I couldn't agree more (but you know this already 😁 )

One important aspect of structuring conventions is to share a common protocol. The logic path is to share the same requirements across projects. This will also give everyone an incentive to push all our existing OSS to new levels. The more implementations we throw at them, the greater they will become.

I think we can start by creating a base Podfile that all new projects will use.

So in this issue, I'd like to discuss which OSS should be marked as required and which are optional.
They could required by another reusable Story but that is a more in-depth discussion that we will take later on.

Right now, it is super easy and fast to set up a new project when doing OSS, we don't have the equivalent for actual Xcode projects. Imagine living in a world when you can generate that thing in under 10 seconds, now that is a world that I want to live it. Let's make this happen! 🚀

Make a branch on these repositories with the name swift-3

Make sure to migrate the tests and update the Travis configuration as well.

Please write your name after the pod that you intend to update;

Marking them as done includes getting the test suite up and running on Travis with also the demos working! :)

List of pods

• Aftermath - Vadym
• AftermathCompass - Chris
• AftermathSpots - Chris
• AftermathTools - Chris
• BarcodeScanner - Ramon
• Brick - Chris
• Cache - Vadym & Ramon
• Compass - Khoa
• Fashion - Vadym
• Fakery - Vadym
• Hue - 
Chris
• ImagePicker - Ramon
• Imaginary - Ramon
• Keychain - Chris
• Lightbox - Ramon
• Malibu - Vadym
• Morgan - Ramon
• OhMyAuth - Chris
• Pages - Khoa
• Presentation - Vadym
• Spots - Chris
• Sugar - Ramon
• Tabby - Ramon
• Tailor - Chris
• Transition - Ramon
• Walker - Ramon
• When - Vadym
• Whisper - Ramon

I also made this thing to try the collaboration feature in the new Notes app.

References
The Travis CI Blog: Xcode 8 Beta initial release!
https://blog.travis-ci.com/2016-06-13-xcode-8-beta-initial-release

I think we should create a single .swiftlint file with a set of rules which must be used in every project. Then we avoid comments in PR's like "remove the newline", "fix indentation" or "rename this var".

I think this needs to be discussed as well. Do we have any apps (except Thyme) that don't authenticate user?

This also has some improvements so far

I see great potential in the Aftermath repository, it hasn't reached 1.0 yet but so far it as helped a lot when setting up a the flow in one of our internal products. Even more so when you combine this pattern with other libraries like Compass and Spots.

For a project, there is usually 1 person that uses Certificate signing request to generate distribution certificate and push notification certificates, and they are kept in his Keychain. When some others need it, he just exports the .p12 files and sends.

Since we will be involved in other projects and / or help on that, I think we should store all the .p12 files centrally. Github is a good candidate 😉 . Also fastlane seems to have a tool for that https://github.com/fastlane/fastlane/tree/master/match

What do you think?

This goes related to #17, but what I want to mean is the using of the app in offline mode. Should we do some kind of behavior for the user to be able to like stuff, etc.? I think we should. I know @vadymmarkov did this, as we discussed it, and I'm pretty sure he made a library. Cannot find it.

Edit: Found it! https://github.com/hyperoslo/Offline

The guy who made Injection for Xcode has refactored his plugin to be a separate application. It should now work without having to unsigned Xcode which is super great. It looks really neat so I think we should try it out to see how it works.

https://github.com/johnno1962/InjectionApp

I like where the development of Tabby is going, it is already way more flexible than the regular implementation. I think it should be included into Foundation when it reaches 1.0.

All right, here it is. The ten dollar question. I like Realm with the setup I had in my current project (inspired 95% from the one I worked on before that) even though it can be a bit weird (crash sometimes, invalidated objects (not now anymore), but you know). We could cache requests, does it fully work as intended? Do we have to do something else?

What do we want to do here. I think having the app available in offline mode should be a requirement everywhere.

I think it should be a requirement to have the same project structure in future apps. Then it's easier to enter into the app developed not by you. But at first we have to define this structure and conventions to follow. So flat, nested, screen-based, feature-based, other?

I think Fashion holds a lot of power when it comes to decoupling view code and styling. This helps a lot when it comes to reusing logic with a different appearance.

Hey guys! So, when doing the swift-3 migration for Spots, I had an idea to improve (in my opinion) the naming in the framework. This would involve removing the Spots prefix that is used both for internal and external components used in the component. As @RamonGilabert mentioned on Slack, being consistent is key.

So, where should we draw the line on where to use the prefix and when to drop it? Should we always use prefixes for all components in a framework (Obj-C style)? Or should we move away from that and try to rely more on module name spacing.

Examples

First example with implied name spacing.

let controller = SpotsController()

Without naming spacing.

let controller = Controller()

Without naming spacing with project conflicts

let controller = Spots.Controller()

Personally, my vote is on going for the module spaced approach, I think it is very hard to find a good middle ground when to include the name spacing and when to exclude it when building framework if we go for alternative one. To be truly consistent, without to many rules, then everything should use the prefix.
What do you guys think?

ping @hyperoslo/ios

@RamonGilabert did some investigation in regards to translations services and found https://localise.biz.
I think there is definitely room from improvement when working with localisation and a service like this would come a long way to solving the super mundane task of having to add locales from a chaotic Google document.

For me this is a no brainer, doesn't have to be Loco but that one was the winner when @RamonGilabert did his investigation. The neat thing about it is that it supports multiple platforms so that backend, Android and iOS could use the same data source for the locales. You just download the file, included in your project, and if you use this in combination with R.swift #10, you don't get any magic strings and you get compile errors if a locale is removed or the key changes, that way you won't end up in a situation where you ship something and locales are not mapped properly.

As stated above, this is not a iOS service so this is something that we should push for to make a defect standard within Hyper, because everyone hates to maintain those stupid Google docs, even the people how make them.

I add here the checklist for things to do during Swift 3 migration

Project

• Open project with Xcode 8
• Choose Edit -> Convert -> To Current Swift Syntax, and choose Swift 3. Ensure that SWIFT_VERSION = 3.0 is set in project file
• Update demo projects to Swift 3
• Follow https://swift.org/migration-guide/

Cocoapods

• Add .swift-version like echo "3.0" > .swift-version
• Add s.pod_target_xcconfig = { 'SWIFT_VERSION' => '3.0' } in .podspec
• Bump and tag new major version

Carthage

• Make sure xcode-select -p points to Xcode 8 toolchain

Travis

• Update osx image osx_image: xcode8 in .travis.yml

README

• Add badge ![Swift](https://img.shields.io/badge/%20in-swift%203.0-orange.svg) to README

The flexibility of easily having multiple network stacks is beyond useful. Also, asynchronous promised based networking is a real pleasure to work with. I strongly recommend this component as a front runner as networking stack for our upcoming projects.

We kind of jumped to conclusions when it came to assume that we should go with Cocoapods over any other service out there. So I'll just add this issue. For me it is a no brainer for now, Cocoapods does the job and is way faster to setup than Carthage.

I was thinking, to minimise the number of comments (if you agree that is) should we try and use reactions to display if you agree with the previous comment or not. Not to remove comments all together but you get a bird-eye view of if we are all in agreement or not.

What do you guys think, you know what to do

👍 👎 ?

😁

No comments here. Easy.

I think we have to disable email notifications in our open source libraries, it's just annoying.

notifications:
  email: false

When we add method, property (compute, associated object) to extension on UIKit class, there might be conflict even if we make internal/private extension in the framework. Like with Fashion, users can't add property names styles to UIView classes?

There are some posts about this

• https://pspdfkit.com/blog/2016/surprises-with-swift-extensions/

To avoid that, I think we need to add a prefix. Then what prefix should we use?

Regardless of tests, it's nice to have Travis just to be sure the project compiles. If we use CocoaPodsit should be pretty fast I guess.

I know it's a minor thing, but would be nice to have an agreement about class/struct structure. What I propose is the following:

- lazy vars
- computed vars
- stored vars
- init
- functions

But maybe it makes more sense to have computed vars after init, next to functions.

What do you guys think @hyperoslo/ios

No brainer. Every app has images coming from the backend. Every app needs to cache those.

Hi, besides #28, the question of when should we go with Xcode 8 and Swift 3, and also use iOS 10 as the base SDK?

What do you guys think about fastlane, should it be something that we always setup or is this something that we should use for edge-cases, like our own product, where we create multiple builds of the same application?

fastlane takes a lot of time and is rapidly changing, I can remember spending quiet a lot of time just maintaining fastlane just because of version updates and doing gem update fastlane can be tiring.

But it also has it's upsides as you can easily invoke the command and head to lunch (or what ever other thing that you are doing) and just wait for the thing to release. The downside is that if it doesn't work the first time, the time that you initially set out to save will be lost because of configuration tinkering etc.

I'm torn on this one, I find it super convenient when shipping new versions to staging but I am far from amazed when it comes to shipping things to iTunes Connect etc.

Maybe the problem is that we really haven't dug into the gem enough to actually know what it is all about and how it works, or we adopted it to early and had to change everything as the gem matured. I don't really know the reason but I think that we should definitely discuss this further.

When we push a new version to the App Store, we should always create a tag or release on GitHub, so that we can quickly checkout the version that is in production whenever we need to make hot fixes or test older versions for whatever reason.

What do you guys think?

Just before leaving the office on Friday, me and @vadymmarkov had a brief discussion about reusability and conventions. We were discussion the reusability of stories in applications, this might be hard to achieve for all stories. Making it reusable takes more time than to write one that is tailored for your application. So we concluded that not all stories should be intended to reused, instead all stories should be written by a clear convention. So far all the stories that we have written are pretty much the same, which is a really great thing. If everyone learns that convention, then you don't need to context switch between applications.

However, this discussion sparked another potential great idea. We got the idea to write a library with some core UI-kit to be used when creating component based UI's. To explain it in a short sentence, it would be a collection of SpotConfigurable views that would be the base for all applications.

I think this would be a great thing to get started with, so when you set up your new application, you include this library and you have the base classes for setting up UI. The components will be styled using Fashion so that all of them look and feel unique to your application.

Here are some components that would be good to have in this library.

• Default application cells that use title, subtitle and image from Brick. Much like a normal UITableViewCell with the style .subtitle.
• UI toggles.
• Input fields.
• Basic article cells (simple feed items).
• Background image cells.

Starting out, I think we should create cells that we already use today. We have loads of different cells right now but they could be made as one configurable one.

And we need a name for this library.

We have had some discussions about naming and new API's, one thing that we haven't discuss but has burnt us in the past is the naming of internal components vs framework name. Right now we have an issue with Compass that we use that name in the framework and the framework shares the same name. Because of this, we lose the namespace for that library, which can put us into a deadlock when it comes to conflicts.

I propose that we try and avoid using the framework name inside of the library, in the past we saw this as a necessity but it is causing more problems than it solves.

What do you guys think?

References

hyperoslo/Compass#40 (review)

I think it should be here too 😄 As of Swift 3 and minimum deployment target is gonna be iOS 9+ soon. I think we can adapt Sugar to that. I would love to move some common, helper code into Sugar. It does not need to be used in our frameworks, but when it is in the project, it is very useful

This is a good one, and I'm torn on this. I find the syntax why more contextual in Quick than I do in XCTests as XCTests require this long method names that are hard to describe in-depth without reaching the line length recommendation. However, having to do carthage bootstrap or pod install just to be able to run the tests can be a bit cumbersome... well that mainly goes for carthage, because it is as fast as trying to outrun a Tesla riding a dead horse.

I think XCTests can improve by adding documentation to the tests but you still end up with the syntax. What do you guys think, what do you prefer?

It got a bit inspired by http://khanlou.com/2016/09/swifty-delegates/ that @onmyway133 shared in the previous discussion. So I wanted to run some stuff by you when building delegate methods.

I would propose that we start moving towards what the article is describing.
To give you a concrete example from the Spots Swift 3 migration.
I'd like to change the public API for the SpotsDelegate method that gets invoked whenever someone taps on an item.

Before

func spotDidSelectItem(_ spot: Spotable, item: Item)

After

func didSelect(item: Item, in spot: Spotable)

I think that reads much nicer.

What do you guys think? @hyperoslo/ios

I think we all care about compile time now, as for some projects it takes 3-4 minutes to compile. Perhaps we could share some techniques we use to fix and reduce this time.

There was this https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode but Xcode 8 no longer accepts custom plugins

Just found this http://khanlou.com/2016/12/guarding-against-long-compiles/ which hints about this flag -warn-long-function-bodies=100. It adds warnings in Xcode for every place the code takes longer time to compile. We can try 😇

It could be time-consuming, but in theory it shouldn't. If we use constraints and size-classes properly, we'll get universal layout almost for free. If we think about it from the beginning it's much easier to optimise the app to look good on any iPhone and iPad screen size.

I think ideally we shouldn't look into project specification for device support, but just go universal by default. What do you guys think @hyperoslo/ios

From time to time, it can be very useful to include client-side logging for applications. A really easy way to do this is to setup Sentry (https://github.com/getsentry/sentry-swift). We have this implemented in our own products to trigger alarms for critical parts of the application. I don't know if it can be considered a requirement but I think it should be on everyones radar that this kind of feature exists and is available for anyone who wants to implement it.

When we decided on going with Sentry, we made that decision because the backend also uses the same logging system and it is good for PM's to have it all in one place, we also have our own Sentry server which was also a deciding factor.

With that said, it might not be the defacto answer to what we should use, the bug reports can be a bit wonky at times if you don't set it up correctly and the overview is not super optimal. But it does work and like I said earlier, it is really easy to setup and send "alarms".

Not a big fun of this library, but still tend to use it in every project. Maybe it's not a good candidate to be in the list of required if the project doesn't have networking at all, but it doesn't happen very often. It's good to notify the user that there is no connection and we need to know when it's time to cache/replay requests.

I find that R.swift is really good to get rid of magic strings in a project. It is really easy to setup and super fast to run (being apart of the build process). I think this can be a great improvement to our future setups.

@hyperoslo/ios I think we can use https://github.com/onmyway133/MainThreadGuard in our Swift projects and https://gist.github.com/drct/bb4b1f93f8790cca9c9f for ObjectiveC. Issues related to accessing UIKit from another thread are tricky to deal with, so it's nice to catch them during development.

I think Compass could be put to universal use as it opens up for deep-linking and app-to-app communication.

I think it would be great to do more UI testing, some things are hard to unit test and won't really give you what you need. I think we have some room for improvement here. But the question is, should it be something that we always do? I think it should, as long as we find a convenient and fast way to do it.

Following up on #17, so here we can discuss the option that we have for what database to use if you have a need for one. Should we start listing a few?

• CoreData
• SQLLite
• Realm

Do we have any more contenders here?