(iOS) lifecycle: updates

ios/lifecycle/documentation.md

@@ -2,7 +2,7 @@
 
 You can defined your own documentation while coding for your functions to be properly documented with the parameter types, information of what it would return with different type of conditions. I believe that in most of the projects were we already can inspect the codebase of a function to better understand, it doesn’t matter but for quick glance to get the bird eye view of the calling method is great. Also it is more future proof in terms of less work ahead if you wanted to make the whole class in a package library type of scenario.
 
-## Headers
+## Headers | Annotations
 
 // MARK:
 
@@ -11,6 +11,7 @@ You can defined your own documentation while coding for your functions to be pro
 // FIXME: 
 
 
+Good article about organizing your swift project with [this article](https://cocoacasts.com/organize-your-swift-project-with-annotations-todos-and-fixmes)
 
 ### Old Headers
 

ios/lifecycle/localization.md

@@ -57,3 +57,9 @@ private enum Texts: String {
 }
 ```
 
+## Third party
+
+Lokalise - translation management system for end user clients. 
+Automation around localization and QA process towards supporting various languages or regions.
+
+[dev | ios sdk](https://developers.lokalise.com/docs/ios-sdk)

ios/lifecycle/protocol.md

@@ -15,6 +15,13 @@ My reasoning:
 This is keeping up with good approach on test-ability of this feature for unit tests and support dependency injection in future. 
 It also could be used as a TODO: marker when you have protocols with functions definition defined which needs to be implemented.
 
+> what made you make this a protocol? b/c we could easily made this a function, just your thought process around it.
+
+- Having protocol makes it easier for the implementer to not introduce more things than necessary. So you start with what is the MVP of that same class, function or properties.
+- It also kinda helps in dependency injection and creating mocks in unit tests.
+- It helps us to also easily allow us to pass protocol as a type for future generics using Protocols with associated types
+- It helps the conforming object/instance of the protocol to have default implementation via `protocol extensions`. Thus guaranteeing default behavior like an optional default nil `let unwrappedValue = optionalValue ?? defaultValue`
+
 ## Combining Protocols
 
 ```swift