What is the length of the file, as stored at the pathname?
If you remove that file and run the program, is the file recreated? If so, then your file-writing code is working. The problem lies in the contents of the NSArray. If the file is not recreated, then you have a file-writing problem. Notice how I have broken the problem into two possible outcomes, and logically determined what each outcome means. This is a fundamental analysis skill.
If the file is recreated and has a non-zero length, then exactly what data is in the file? If it's an array with no elements, then that means your NSArray contained no elements when it was written. If it's an array with one string element, and the text of the string is "", then your NSArray contained @"" when it was written. Again, notice that I've broken the problem down into sub-components (contents of file, two possible interpretations of file contents), and logically determined what each one means.
If your array contains no elements, then takeText.text must be returning nil. If your array contains one "" element, then takeText.text must be returning @"". Here, I'm logically working backwards from the two possible outcomes, and making testable statements about how the NSArray 'values' came to have either zero or one element.
If takeText.text is nil, what might cause that?
One possibility is that takeText itself is nil. There are other possibilities. You have to look at the variables while debugging your code.
If takeText.text is an empty string, what might cause that?
A testable statement means an observable condition or state of some variable, whose answer can be determined by running the program in a debugger and actually observing what happens. If you can't determine the answer by observing something, then it's an untestable statement, and has no practical use because it can't be tested by any observation.
If a testable statement is too complex, it needs to be broken down into smaller testable statements. This is called decomposition and is fundamental to creating all software.
If you can't create testable statements about your code, then you probably don't understand what the code is doing, or what its sub-parts are doing. You fix this by learning what the code is doing. Otherwise it's all just magic, and you can't debug magic.
All the above is nothing but basic debugging logic and analysis. The logic means understanding the logical consequences of different observed states and outcomes (file exists or it doesn't; file contains some data or it doesn't; etc.). The analysis means working backwards from outcomes, and working forwards from existing state (a string variable is either nil or "" or some other text; an array contains either 0 or 1 elements; etc.).
As you see, I have already created the file (.plist) so I can't check this possibilities, what do you recommend, change the method to create the file or just leave it there blank until someone will enter a value in it?